to be on the same page as to both where and why they are trying to improve. If there are disparate views, different parts of the organization will actually work against each other – often without even being aware of this. Lean provides a common vision – our goal is speeding time to market. While this may appear obvious, I would suggest that most organizations do not actually live like it is true. The following are common attitudes we find that are evidence that people are not looking at the big picture of shortening cycle time:
- Product portfolio management is merely looking at what’s needed and not considering the loads (and therefore possible inefficiencies) they are putting on their teams
- Developers are just trying to get the code done
- Testers are just trying to get the code tested
- No one is paying attention to what the costs of integration, deployment and support are except for those doing those jobs
What our means are to get there
So how does Lean help us achieve our goals? Let’s look at the common problems we mentioned earlier.
Business stakeholders not understanding what they need created. This results in too many and too large projects which overwhelm the teams. Lean adoption will suggest we need to do product portfolio management to alleviate this challenge. More importantly, Lean suggests that what is developed must add value to the customers, not merely be software with great features. Adding value to customers means to focus on their operational and commercial value streams. This gives us a way to connect our software development efforts to our customers (whether they be internal as in IT organizations, or external as in product companies).
Teams not knowing how to work together. For years I’ve worked with many teams and lamented the ineffectiveness of Scrum-of-Scrums. Coordinating the work of agile teams that are dependent upon each other or who are working on different parts of the same feature is particularly difficult when the organization does not have a really good method of coordination already in place. While Lean focuses on cycle-time, it can also be used to think about the time until you get useful feedback. When teams need to coordinate together, one level o useful feedback is when they integrate their work. If integration takes place after all of the teams have completed their work on the feature in question, this work may take a considerable amount of effort – merging branches as well as larger integration tests. Lean suggests giving smaller pieces to the team to get them done more quickly.
Inspired by Lean’s focus on time, in particular, getting feedback quickly, I have seen that selecting stories and then giving the appropriate fragments of these stories to the appropriate teams, speeds up integration and greatly reduces the need for coordination. The details of doing this is beyond the scope of this article but will be presented in December’s edition of Agile Journal.
Too many projects being dumped on the teams. This can be addressed by limiting how many projects are in play at once. Even if Scrum is used, limiting work in progress at this project level is still a very powerful method.
Teams not knowing how to deliver value in small increments. At the team level, either Scrum or Kanban may be effective. We should chose which one we want based on the ability to form teams as well as the ability for team members to adjust to change. If Scrum is chosen, it is critical that many of the practices that Kanban suggests (e.g., visibility, explicit policies,