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:
| Component teams are structured to match technical layers, components or services. Examples include; iOS team, Payment API, Data Services, etc. Customer and/or Business valuable backlog items are split across the teams, each contributing functionality in the components or services for which they are responsible. |  |
|
Feature teams are structured to match business value so that they take end-to-end stripes of customer valuable functionality and deliver them within the boundary of a single team. Unlike the Component teams, Feature teams work across all components related to providing the business functionality. |
 |
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 :
- Specialised roles and expertise are easier to fit into specialist component focused teams and it would seem logical that people with the deepest knowledge in a given component will do the best job!
- Related to the first point - departmental boundaries are usually easier to accommodate with component teams.
- Clear boundaries of responsibilities for design, build, test and bug fixing.
- Clear and well understood inter-team interfaces/hand-offs that match architectural platforms and layers.
- Teams are somewhat decoupled so that they can work independently without breaking and interfering with each other’s work.
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.
Challenges of the Component Pattern
Long Lead Times
Record 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:
- More upfront work on architectural design so that business valuable backlog items can be chopped up into their technical components and handed out to the teams. Technical Product Owners are often added to the mix to run this process per team.
- Once a team finishes a component it will need to be integrated and tested when the dependent components are complete. Integration and test teams are common additions.
Early Commitment
In 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 Challenges
Inter-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.
- Problematic integration with extended effort and time to rectify, often with less than optimal joins between components.
- Late discovery of load & performance challenges leading to delayed releases and/or poor production performance.
- Expensive rework and potential for higher cost of ownership of final solution once in production.
Sub-optimised Design
One 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:
- Loss of business context of the overall objective as teams are too removed from the business goals, working against decomposed technical backlog items.
- Technically sub-optimised decisions within architectural layer that seem to make sense except when viewed from the perspective of consuming functionality or the overall system.
- Conway’s Law: Solution architecture reflects the team structure rather than the business services it is meant to deliver
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 Pointing
When 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.
Conclusion
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:
- Reduced lead times for producing working business aligned features, with faster feedback loops and reduction in process and role requirement.
- Reduced dependencies and management overhead.
- Increased team empowerment and architectural flexibility with later commitment.
- Reduced excuses for a build-up of technical debt with honest metrics showing realistic progress, or lack of.
- Easier to optimise teams’ workloads and focus on the highest value backlog items.
- Issues and bugs have clearer responsibility with the team that was responsible for implementation.
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:
- Deliver working software frequently – with “working” validated by a DoD that is as close to potentially shippable as practical.
- Working software is the primary measure of progress – track your Story Cycle-time, from the first work to potentially shippable.
- Maximise team autonomy and align to business value through shared purpose.
- Optimise feedback loops to maximise learning, validation of assumptions and reduction of risk. Not just what, but also, how long!
- JIT – retain plan and design flexibility as long as practical to maximise the amount of information before decision commitment.
- Maximise collaboration - reduce impediments to information flow.
- Just enough process and roles.
- Use process tools wisely, if they get in the way of collaboration or create too much bureaucracy then change the way they are used.
.