Multiple Scrum Teams and Multiple Team Scrum
Doing Scrum properly tends to be difficult. Scrum shifts an organization from a project mindset to a product mindset, and asks for a working, “done” increment of the product every month (or less). Scrum seeks to establish a Scrum Team to do this, one that is composed of a Product Owner, a 3–9 person Development Team, and a Scrum Master to coach the Scrum Team and the wider organization.
Most organizations I work with tend to have groups larger than one Scrum Team. Patterns emerge, and I usually see two distinct patterns: Multiple Scrum Teams, and Multiple Team Scrum.
Multiple Scrum Teams works well when there are multiple products. Each product would have a Scrum Team to work on it. This ensures that the product has the necessary development capability to grow. Key is properly defining what the products are: a product must be defined from the customer perspective, not from the technical perspective.
Multiple Team Scrum works well for a large product that needs the equivalent large product development group. The product would have one Scrum Team, with the group organized as multiple Development Teams working with a single Product Owner (and thus a single Product Backlog). This ensures that the entire group focuses on the whole product, aligned to the single Product Owner. Key is for Development Teams to learn to coordinate with each other, and work on the product as a whole together.
Design is about tradeoffs, and some observations are:
- Multiple Scrum Teams tend to struggle with cross product collaboration. This becomes a problem if the products have high cohesion with each other. Most organizations introduce an additional layer of complexity on top, such as a program or portfolio layer — this reduces whole product focus, and moves teams farther from the customer.
- Multiple Team Scrum tends to be a struggle at the start. Having multiple Development Teams work together is a totally different challenge than having a team of up to 9 people work together. Most organizations introduce additional complexity in roles that only manages coordination — this is not a good idea, as this limits self-organization in the teams, leading to a rigid structure that reduces emergent practices.
Take away is to structure large teams around an appropriate pattern. There is no perfect pattern, only a pattern whose tradeoff is something that the organization can live with.
These days, I tend to start with one Scrum Team first, do Scrum well, and then emerge the pattern that naturally fits in the situation. This allows the organization to learn how to do Scrum well, in order to tackle the additional complexity of large product development.
Update: I gave a talk on Multiple Scrum Teams and Multiple Team Scrum at LeSS Meetup Philippines last 15 July 2020. We did not have a recording of the talk, but I’ve shared the slides online.
