91 Multiple Teams

Your Organization is Designed to Impede Agility

Introducing Scrum without simplifying the organization’s structure and policies leads to change theater and no real improvement. Large organizations are usually just pretending.6 Successful adoptions of Large Scale Scrum are both top down and bottom up.

Scrum addresses uncertain requirements and technology risks by grouping people from multiple disciplines into one team — in one team room — to increase bandwidth, visibility, and trust.

Adding too many people to a team makes things worse. Grouping people by specialty also makes things worse. Grouping people by architectural components (a.k.a. component teams) makes things worse.

Figure 12: Communication pathways increase as a square of team size.

Feature Teams

Fully cross-functional “feature teams” are able to operate at all layers of the architecture in order to deliver customer-centric features. In a large system, this requires learning new skills.

As teams focus on learning — rather than short-term micro-efficiencies

— they can help create a learning organization.

Team 1Team 3UserLayerBusiness Logicrsistence Layinformal working grouperPeyerLaTeam 2Interface

Figure 13: Feature teams learn to span architectural components.

One Product Backlog, One Product Owner

In Large Scale Scrum, multiple teams share a single Product Backlog prioritized by a single Product Owner. They share the responsibility of maintaining this backlog. To avoid asynchronous dependencies, they collaborate across teams in one shared Sprint, using overall and multi- team versions of the events described in this card, often with team- appointed representatives.7 As in single-team Scrum, they attempt to develop one properly tested, integrated, shippable product increment every Sprint.