Agility at Scale - Platform versus Product Concerns
A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood.
This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.
Outline/structure of the Session
- Definition of the problem for the session, specifically excluding the standard "scaling Agile" problem, and specifically including the problem related to dependencies between core component silo teams and multiple product development teams
- Definition of what are Product Concerns and what are Platform Concerns
- Brief explanations of the grading system used (the 7 Deadly Lean Wastes) to compare six solutions to the problem [I've coached organizations where various flavors of each solution were used, and I'm using their results but witholdng identifying information]
- Compare and contrast the six solutions
- In depth explanition of the "Scrum Everywhere with Core Component Kanban Teams" solution and how to make it work
- Concluding remarks and final thoughts
- Use of pure waterfall silos, pure Scrum silos, hybrid Scrum product teams with core component silo waterfall teams, hybrid Scrum product teams with core component silo waterfall teams and "Guest Stars", and even spinning off core component silos into companies all fail organizations.
- Lean thinking explains the failure modes and helps us keep from repeating those failures
- A more complicated model involving core component teams running in Kanban and embedding with Scrum product teams works, so long as you also have core component teams using Scrum for development of future core component capabilities
- These concepts are explained, and experience with how this has worked in enterprises I've coached is explored
Managers who organize team makeup and are wondering how to engage individuals from key component silos