Mike Cohn and others present their case to why you should consider structuring your teams around software "features" rather than software "components".
Cohn recalls a past video game development client of his whose component team organization style led them to create "weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player."
He uses this story to setup his advice for agile organizations to prefer "feature teams", teams responsible for the development of end-to-end features, as opposed to "software components". He goes on to outline the following five advantages of feature teams:
- "Feature teams are better able to evaluate the impact of design decisions." Having built end-to-end functionality garners real feedback on how well user's desires/needs have been met; having worked across architectural layers informs about the outcomes of internal/technical decisions.
- "Feature teams reduce waste created by hand-offs." Counting on handoffs creates risk of component teams not meeting the needs of other component teams and/or of going beyond what was actually needed.
- "It ensures that the right people are talking." A feature team creates an environment for everybody in the value-chain to stay plugged in with each other.
- "Component teams create risk to the schedule." Work of component teams must be integrated in order to obtain anything of tangible value; planning this activity is difficult as it depends on unknown information scattered across multiple teams.
- "It keeps the focus on delivering features." At the heart of the agile mantra is for the team to deliver "working software" each iteration, feature teams help to keep this at the forefront of everyone's focus.
Probably the most notable source of recent support for feature teams comes from Bas Vodde and Craig Larmen in their book Scaling Lean & Agile Development. An article by Mike Cottmeyer said this:
Larman and Vodde summarize the ideal feature team as cross-functional, cross component, and co-located. They are working on complete user functionality, the team is made up of generalizing specialists, and typically six to eight people in size. In other words, our prototypical Scrum team.
[Larmen and Vodde] also point out several challenges with the feature team approach.... which I really appreciated by the way. Common barriers include... concurrent access to code, shared responsibility for design, difficult to learn skills, and organizational structure. Their assertion is that with modern tooling these challenges can be overcome... but it could take years.
In the same article Cottmeyer points to a contrasting message from Dean Leffingwell's Scaling Software Agility book that provides support for component teams:
The component team [suggested by Leffingwell] shares many of the same attributes of the feature team [suggested by Vodde/Larmen and Cohn] in that it is small and contains all the skill-sets necessary to delivery the user story. Leffingwell's component team is empowered, self-organized, and self-managing. In short, they are a typical Scrum team. But... and this is a big but... they are working on component features... not end user features.
The comments to this article provide further insight by Leffingwell, Cottmeyer, and Vodde into the context of their views.
For some former discussion on team structuring, including other ideas on feature teams, check out this previous InfoQ article.
