Scaling agile teams – by features or by component?

Agile methods are of clear benefit while our projects are small enough to be delivered by a single small team responsible for the full life-cycle and incorporating all of the various necessary specialisms. As the project size increases we will eventually reach a state where we face a challenge since the team size becomes increasingly difficult to manage and we seek to provide internal structure through sub-teams. At this point we will typically need to establish the axis along which the team is split.

Option 1: Component orientation
In a large systems it is common to find developers who align themselves to components. This presents a simple option of splitting the team along component lines. By doing this we create a need to split user-centric features into component features and subsequently re-combine and verify the end-to-end behaviour.

In this way we have benefited from natural affinity of developers to components at the cost of lead time. The benefits of this approach will depend on the degree of specialisation and the degree to which specialisation aligns with co-location; this ownership of components by location is common in large systems development organisations. A further drawback, however, is the balance of features to components, it is not uncommon to see feature prioritisation determined by availability of component teams in preference to value, increasing the degree of generalisation increases a teams flexibility to build the next most valuable feature independent of the impacted software component.

Option 2: Discipline
By splitting a team by discipline we risk longer lead times and can easily risk further engraining waterfall like thinking such as stove-piping the organisation with a “throw over the wall” attitude.

However, all is not lost. Kanban systems have been shown to offer a model that recognises the existing flow of work while encouraging innovation to reduce lead time of features. Kanban systems have also been used successfully with teams of up to 50 people, considerably larger than the norm for Scrum or XP teams.

Option 3: Location
Co-location is known to be a strong influencer of team effectiveness. With this in mind it would be naive to ignore location in a discussion of team forming. A co-located team would be expected to out-perform a dispersed team where all other aspects are equal. However, dispersed teams can be used to good effect in order to leverage benefits of feature teams. In this situation we should learn the lessons of those who have successfully built effective dispersed and distributed teams.

Option 4: Feature
The preferred model for team structuring in most Agile methods is to orient teams around delivery of customer valued features. This model encourages increasing levels of generalisation according to the profile of the features being delivered by the team. While integration issues can still arise with feature teams the use of continuous integration will mitigate risks while feature selection can help to limit interaction between teams. Where the project size is very large or the problem domain very complex it is possible to orient feature teams around areas of the problem domain. This is what Craig Larman terms Requirement Areas. By allocating teams to requirement areas we support the team in developing their understanding of the problem space investing in specialisation on that axis in preference to specialising in a discipline or component.

Choosing and Blending
In practice we will typically mix these models in a large multi-location team combining the benefits of co-location, feature orientation and component specialisation while trying to manage the limitations of each. By way of a practical example consider an embedded system distributed across the globe. We may choose to recognise the specialisation of the team that develops the low level board support packages; this team delivers low-level facilities to feature teams. We lean towards feature teams for the majority of user-feature development. However, for high volatility or high risk features we might choose to have co-located feature teams in the vicinity of our key customer groups. This focuses the agility of co-located teams where it adds the most value.

2 Responses to “Scaling agile teams – by features or by component?”

  1. David Draper

    When scaling from one team to, say, three I might be tempted to scale by splitting but if the scale is greater than that I’d worry about dilution.

    It may be more effective to keep an effective team together and have new teams learn together rather than importing an expert. One model to consider would be treating the mature team as POs to new teams in order that they can guide and influence new teams while retaining their own identity.

    Thanks for the comment.

    Dave.

  2. Carl Pearse

    I fully support feature teams where the teams are long lived. What about in organisation’s that scaling very quickly? Developer experience is then hugely influential as agile teams scale the experienced developers often split to accommodate the influx of new developer. You lose a lot of the identity of a team that is regularly changing, but the cross functional developers often retain identity around a component, detracting away from product team.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>