Most projects I am involved in are of such a size that multiple teams are involved. An even when the project itself consists of one team, many dependencies with other teams/departments exists. In theory this is not an issue but in practice it usually is because how the teams are structured.
Some general patterns that I typically see are:
– Discipline Teams: Programmer Team, UI Designer Team, Tester Team, DBA Team etc.
– Location Teams: Zurich, Bern, Ney York, London etc
– Architectural Layer Teams: GUI, Middle Tier, Database, Infrastructure, etc
– Component Teams: Model Component, Computation Component, Configuration Component etc.
What I unfortunately do not see a lot are so called Feature Teams. A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features one by one (Lairman/Vodde).
The characteristics of a feature team are:
– Long-lived: the team stays together so that they can grow into higher performance; they take on new features over time
– Cross-functional and cross-component
– Ideally, co-located
– Work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
– Composed of generalizing specialists
– in Scrum, typically 7 ± 2 people
Applying modern engineering practices, like continuous integration, is essential when adopting feature teams. Continuous integration facilitates shared code ownership, which is a necessity when multiple teams work at the same time on the same components.
One common misunderstanding of feature teams is that every member of a feature team needs to know the whole system. This is not the case because
– The team as a whole, not each individual member, requires the skills to implement the entire customer-centric feature. These include component knowledge and functional skills such as test, interaction design, or programming. But within the team, people still specialize… preferably in multiple areas.
– Features are not randomly distributed over the feature teams. The current knowledge and skills of a team are factored into the decision of which team works on which features.
Within a feature team organization, when specialization becomes a constraint…learning happens. Moving away from component and discipline teams is a difficult but necessary step for those who want to adopt an agile approach. In Scrum, for example, you have a team, a ScrumMaster, and a product owner. These teams work on customer-centric features that are iteratively developed, and in order to do so, they should be a feature team.
There are many advantages to organizing multi-team projects into feature teams:
Impact evaluation: At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)
Waste Reduction: Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
Communication: Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
Risk Mitigation: The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
Customer Focus: Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.
Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.
