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.