These days scaling Scrum is a hot topic. How can I use Scrum to deliver a big product with multiple teams? The most common approach I see at my customers is scaling Scrum by adding more Scrum teams with a Product Owner and Scrum Master per team.
Scaling is about increasing in size. I’ve been told that fire departments scale their operations depending on the severity of the fire. Depending on the scenario, they increase the size of the trucks that join the fight, the number of trucks, the number of people and the coordination and communication process as needed. This approach is what I call Copy–Paste scaling. You ‘copy’ the trucks and people needed and ‘paste’ them to form a larger group while adding extra processes for communication and coordination.
When you apply this scaling approach to Scrum this means increasing capacity by copying and pasting Scrum Teams in your development group. You add Product Owners, Product Backlogs, Scrum Masters and Development Teams. To support and coordinate this growth, organizations typically augment with special roles such as ‘feature owners’. They also add extra layers of coordination, e.g. ‘release train management’, extra processes e.g. ‘integration test phases’ and even additional artifacts e.g. ‘value stream backlogs’. Unfortunately, this approach results in diminished team-customer collaboration, leading teams to focus on delivering components in isolation, instead of an integrated potentially shippable product. And now you are slowing down rather than speeding up.
The Copy-Paste approach to scaling Scrum gets you into trouble rather quickly because of three main reasons:
One of my customers operates in the energy trading business and their development group is distributed across three sites. They initially started with a few teams, but quickly scaled up to thirteen teams over a couple of months due to market demands.
The development group supports a business process that consists of roughly thirteen steps. Naturally, following a copy-paste scaling approach, they formed thirteen Scrum Teams for those thirteen steps. Each team had its own fake Product Backlog, Scrum Master and fake Product Owner. Each team worked on a single step of the business process, even though a feature largely required multiple business process steps in order to deliver value to a customer. Therefore, the teams did not optimize for adding customer value but rather for producing lots of code.
As a result, the teams and “Product Owners” needed extensive planning and coordination in order to align their work and deliver an integrated product. Additionally this model also introduced delay in testing and customer validation; hence more defects, information scatter of a feature across teams and opaque measures of progress. The result was low productivity, high defect rates and unhappy customers.
With large products, there are generally a lot of users. These users typically get value by working in a single area of the product. When there are many such Value Areas in your product, often you find the necessary deep understanding of all those areas cannot be maintained within a single Scrum Team. Therefore, you should scale your Scrum organization along customer domains or Value Areas.
When you specialize your teams along Value Areas as seen from the customer perspective, the teams can focus on a subset of the customers. Therefore, each team needs to understand one customer domain only, while still able to deliver complete features that the Product Owner can sell. Therefore, you only need 1 Product Owner and 1 Product Backlog and no added organisational complexity. You have multiple team Scrum instead of multiple Scrum teams.
You can read more about this in the paper Scale Your Product Not Your Scrum and the Scrum pattern Value Areas.
Scaling Scrum using Copy-Paste
Scaling is about increasing in size. I’ve been told that fire departments scale their operations depending on the severity of the fire. Depending on the scenario, they increase the size of the trucks that join the fight, the number of trucks, the number of people and the coordination and communication process as needed. This approach is what I call Copy–Paste scaling. You ‘copy’ the trucks and people needed and ‘paste’ them to form a larger group while adding extra processes for communication and coordination.
When you apply this scaling approach to Scrum this means increasing capacity by copying and pasting Scrum Teams in your development group. You add Product Owners, Product Backlogs, Scrum Masters and Development Teams. To support and coordinate this growth, organizations typically augment with special roles such as ‘feature owners’. They also add extra layers of coordination, e.g. ‘release train management’, extra processes e.g. ‘integration test phases’ and even additional artifacts e.g. ‘value stream backlogs’. Unfortunately, this approach results in diminished team-customer collaboration, leading teams to focus on delivering components in isolation, instead of an integrated potentially shippable product. And now you are slowing down rather than speeding up.
The Copy-Paste approach to scaling Scrum gets you into trouble rather quickly because of three main reasons:
- Scrum and Agile are based on essential values, principles and practices and just adding more people does nothing about using those at scale.
- Developing software is creative work not production work. Therefore, adding people does not necessarily increase productivity.
- The ability of teams to independently produce valuable and bug-free product every Sprint is essential. Copy-Paste scaling does nothing about improving the required engineering practices.
An example at one of my customer sites.
One of my customers operates in the energy trading business and their development group is distributed across three sites. They initially started with a few teams, but quickly scaled up to thirteen teams over a couple of months due to market demands.
Figure 1: The added overhead of Copy-Paste Scaling. (E.g. The Green Feature is developed out of sync introducing sequential development.)
The development group supports a business process that consists of roughly thirteen steps. Naturally, following a copy-paste scaling approach, they formed thirteen Scrum Teams for those thirteen steps. Each team had its own fake Product Backlog, Scrum Master and fake Product Owner. Each team worked on a single step of the business process, even though a feature largely required multiple business process steps in order to deliver value to a customer. Therefore, the teams did not optimize for adding customer value but rather for producing lots of code.
As a result, the teams and “Product Owners” needed extensive planning and coordination in order to align their work and deliver an integrated product. Additionally this model also introduced delay in testing and customer validation; hence more defects, information scatter of a feature across teams and opaque measures of progress. The result was low productivity, high defect rates and unhappy customers.
What to do?
With large products, there are generally a lot of users. These users typically get value by working in a single area of the product. When there are many such Value Areas in your product, often you find the necessary deep understanding of all those areas cannot be maintained within a single Scrum Team. Therefore, you should scale your Scrum organization along customer domains or Value Areas.
When you specialize your teams along Value Areas as seen from the customer perspective, the teams can focus on a subset of the customers. Therefore, each team needs to understand one customer domain only, while still able to deliver complete features that the Product Owner can sell. Therefore, you only need 1 Product Owner and 1 Product Backlog and no added organisational complexity. You have multiple team Scrum instead of multiple Scrum teams.
You can read more about this in the paper Scale Your Product Not Your Scrum and the Scrum pattern Value Areas.