Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Common Mistakes When Scaling Scrum

DZone's Guide to

Common Mistakes When Scaling Scrum

Introducing Scrum onto a small-scale, 3-person team is relatively simple compared to introducing the benefits to a broader organization.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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 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.

copypastescrum

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 organizational complexity. You have multiple team Scrum instead of multiple Scrum teams.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
product owner ,scrum masters ,scrum master ,scrum

Published at DZone with permission of Cesario Ramos, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}