On multi-team development projects, there are significant advantages in having each team organize around the end-to-end delivery of features as opposed to working on separate components. Fewer handoffs reduce waste and integration-related risks. And feature teams have a clearer understanding of the impact of design decisions. However, in some circumstances, component teams offer benefits.
Editor's Note: This series is excerpted from Mike Cohn’s new book Succeeding With Agile, which examines critical factors in determining how to structure and manage Scrum-based project teams. In part one, the author explained the importance of keeping teams small. Here, in part two, he recommends orienting each team around the delivery of end-to-end user-visible functionality.
When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.
On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of