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, limiting work in progress) be incorporated to enable all parts of the value stream to work better together. The interested reader should refer to our Practices All Scrum Teams Should Follow .
Not being able to create well-formed teams across the organization. Until Kanban, all Agile methods were organized around teams being formed. While Kanban does not require teams, it can be practiced when teams do not exist. This is very useful for those organizations that have people who have specialized skills, expert domain knowledge or are familiar with certain parts of the company’s legacy code and need to be shared across projects. In these situations, forming teams may just not be possible. The mandate of cross-functional teams, while ideal, may just not be possible. It is not possible to easily cross-train someone to learn what a person knows who was around 10-15 years ago when a legacy system was built. Nor is it easy to replicate a person who is a specialist in stress testing airplane wings that requires a Ph.D. and eight years experience. People like these typically need to be available to multiple teams, making the Scrum model inapplicable.
What our suggested path is
It is very tempting to begin your transition to agile methods with a pilot project. Most every company has at least one or two projects that could benefit from doing so. However, I have seen many organizations start their road on agile by merely starting a pilot project without regards to what impact it has on the rest of the organization. This often appears to work, but is fraught with danger. See my blog How successful pilots can hurt the organization .
Our path becomes one of looking at the entire organization. Focusing on adding value and looking to see where we need to start and while keeping an eye on where we want to go. While we may start a pilot project under Lean’s auspices, we’ll do it while considering the entire value stream. Any changes we make will attend to how they impact the broader picture.
The agile community should be proud of its accomplishments over the last decade. Agile is clearly accepted as the model for teams building software. The challenges in scaling agility, however, have shown us that a bigger picture view, afforded by Lean, is necessary. Lean provides insights that can align all components of the development organization – from the business drivers through support. It also gives us insights into how to achieve continuous process improvement and to introduce agile methods in organizations that might not be able to easily accommodate the structural requirements of currently popular methods. I fully expect that this combination of
Using Lean-Agile to Provide the Real Value of ALM
Agile Connection is one of the growing communities of the TechWell network.
|Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery. Join the conversation now!|