Agile experts will tell you the first rule about scaling Agile is … Don’t!
The ideal Agile team model is a single co-located, cross-functional team working closely with the customer. As soon as you involve multiple teams to build the same product there will be challenges and a reduction in efficiency (the amount of value created for a given investment). However, if timelines and product scale are beyond a single team then we consider scaling to a “Team of Teams”.
We attempt to structure the teams and work for maximum effectiveness by staying true to Agile principles and adopting a set of scaling patterns.
There are many potential patterns, however there is usually a fundamental choice between the Component or Feature team pattern as a basis to structure the teams.
This article will consider the pros and cons of these two approaches.
Lets start with some brief definitions of the two patterns:
In our coaching work, we find that most organisations tend to favour the Component pattern as the primary model for team design for reasons that include the following :
So, on face-value the Component pattern looks like a smart choice! Before rushing to a conclusion however, I’d recommend considering some of the challenges generally experienced with the Component approach.
Long Lead TimesRecord the time from when work on a business value feature starts through to the time it is potentially shippable. The collective delays and challenges of the points below all accumulate to produce average lead times that are often multiple Sprints long.
Additional Processes and Roles The Component pattern looks neat on paper but in practice it requires many additional processes. These include:
Early CommitmentIn order to design the component team structure (i.e. identify the components required) and to prepare the technical backlog items, architectural assumptions need to be committed to early. Apart from reducing the teams’ empowerment, it can also lead to later rework when assumptions turn out to be incorrect.
Dependency ChallengesInter-component dependencies can block teams’ work so management and prioritisation of the technical backlogs to optimise the overall flow of high value work becomes a real challenge and overhead.
Invisible Technical Debt Due to the focus of teams’ responsibility on their components, the Definition of Done is scoped to individual team output. In other words, we have a “Team Done” and then a “Done Done” when all components have been integrated and fully tested sometime later. The result of this hobbled DoD is that an invisible amount of debt is being carried, adding significant risk to the project and making forecasting metrics almost worthless (Burnup and Burndown charts are predicated on Done meaning potentially shippable).
Delayed Feedback Loops The decoupled “advantage” of component teams can lead to delayed integration, feedback and learning. Later discovery of issues offers the choice of often expensive rework or acceptance of lower quality.
Sub-optimised DesignOne of the disappointments of the component pattern is that it rarely delivers the quality of architecture expected from a model where the best qualified people are working on their areas of expertise. There are a number of contributing factors that lead to this outcome:
Uneven Workloads One team can become overloaded whilst another may be scratching around for work. A secondary problem of this scenario is that teams are not necessarily always working on the most valuable items, rather they work on items that aren’t blocked by a dependency and are within the scope of their service or layer.
Finger PointingWhen bugs emerge, they often spread across team responsibility boundaries, leading to finger pointing as to which team is at fault and who should resolve the issue.
So as you may have gathered from the above points, I’m not the biggest fan of the component pattern and this if from many years experience, starting with my first attempts to scale Scrum teams back in 2005. I thought it looked like a logical approach at the time
So, does that make the pattern bad? No, not necessarily! All patterns have to be considered in a given context and then if they look promising, try them and then regularly inspect and adapt. There are also many sub-patterns that we can apply to mitigate some of the issues discussed above.
I generally find the Feature team model more appropriate in most situations. This alternative pattern helps to resolve or reduce many of the challenges experienced with the Component approach, particularly:
However, the Feature pattern is no magic bullet and has its own set of challenges, and as for the Component approach, sub-patterns may need to be applied.
As this blog is already way longer than planned, I’ll explore some of these challenges and potential patterns in a later blog…
When considering patterns, judge them against Agile and Lean principles and see how they stack up. After all, patterns should be helping us instantiate these principles.
Some thoughts and aims when considering suitability of team patterns to your context:
RSS
Email Colin Bird
© Copyright 2019 RippleRock
