5 common mistakes to avoid when scaling Scrum

Be aware: when you scale, you scale everything

The main trouble with scaling Scrum is that multiplying teams that don’t work well, will just bring more teams like that, causing further problems. Unfortunately, bad habits scale too. If you have a single Scrum team and it doesn’t deliver valuable increments in each sprint, copying it will just make things worse. Moreover, poor software architecture and development practices also tend to scale together with Scrum, causing greater technical debt and a number of other product problems.

Scaling Scrum requires specific conditions. If you have to do this without any professional support, get ready. It’s best to consider using one of Scrum scaling frameworks (Nexus, SAFe, LeSS, Scrum@Scale) and you need to prepare well for that process. Choosing the framework might be one of the most important decisions in Scrum scaling. It’s crucial to match it to your company’s culture and current situation. At Boldare, we have been successfully using Nexus, but that’s what fits our specific culture and teams. For you, something else might work better.

In this article, we don’t describe the frameworks in detail, but we give you an overview of the most common Scrum scaling mistakes to avoid. Here are five mistakes we consider worth knowing about and preventing.

Mistake 1: Putting processes and tools over individuals

Many companies, when scaling Scrum, get lost in all the rules and processes. That’s one of the mistakes to avoid. You need to remember that processes and frameworks are there to serve your team, your product, your organization. Not to disturb. The SAFe framework for example is full of rules that drag teams into following them strictly, and forgetting what’s important. When this happens, team members may feel limited and hesitate to initiate team conversations, brainstorms, or problem-solving discussions.

Another thing is applying more Agile rules and terms without the accompanying mindset. Large organizations tend to use Agile terms - like ‘squads’ or ‘tribes’ - for teams and whole departments, but that’s often the only change they make. Scaling Scrum is not about adopting new terms. First it requires shaping an Agile organizational culture, by coaching employees in an Agile mindset, so they are equipped with all they need to focus on delivering value.

Similarly like building products, scaling Scrum should be done in small, manageable iterations, with feedback and planning in between them, with adjusting the scaling framework to the organization’s needs.

Mistake 2: Building teams around product components

When multiplying Scrum teams, it is easy and tempting to focus teams around product components instead of product features. When you ‘cut’ a customer journey into small pieces and assign the product development of each of these pieces to a different team, it might get quite difficult to integrate the components and deliver great value to users. If team members focus only on their own chunk of a product, they often tend to lose the wider product perspective and understanding.

Here are some potential consequences of building teams around product components:

• missed deadlines (as it takes time for isolated ‘component teams’ to synchronize and integrate their separate pieces of code),
• particular teams develop expertise in a narrow product aspect or area and don’t grow their skills and competences,
• coordinating the work of ‘component teams’ requires additional roles in the organization.

What should be done instead? Instead of building teams around components, it’s safer to focus them around product features. A ‘feature team’ works with many different aspects of the customer journey. It’s especially important for products at the early stages of development but also for those in the product-market fit phase.

You might be also interested in the article:

Agile in practice #5 - Does Agile development work for every project?

Mistake 3: Scaling Scrum without proper preparation

Many organizations start scaling Scrum without previous training and consulting and that’s a huge mistake. Of course, the motivation is clear - to save on budget as scaling Scrum is expensive. It requires dozens of training and consulting hours to prepare all teams and respective departments for the change. Implementing a new Agile culture without understanding the basics of it can be hard and frustrating, not to mention the lost time and money.

It all needs to start with the leaders. They are the ones that are able to transfer and spread a new mindset among the teams. Top management should be one of the first groups adopting Agile manifesto principles and practices. What can help them is in-depth analysis of management models and rules that have been used so far, and building a strategy of changing them iteratively. They need to engage in the company’s evolution as they are the key people deciding on major organizational changes that will include many aspects of running business:

• structure
• communication rules and tools
• strategic roles
• KPIs
• ways of dealing with contractors
• budgeting
• tools and practices used within the organization

You might be also interested in the article:

Remote Work

How to build psychological safety for more efficient and agile teamwork

When Agile transformation takes place, the business vision might also need adjustment. Scrum teams need to have a strong understanding of the business goals and overall vision of their organization. Only then can they work towards common benefits. It’s also recommended to set definitions of done for every team and prepare a common understanding of terms and rules to follow.

The preparation for scaling Scrum should also include preparing for integration and coordination challenges. With multiple Scrum teams and no separate role to coordinate the work between them (there are no project managers in Scrum teams), the structure won’t be effective. There are many dependencies which stand in the way of flawless communication and integration between all systems. To deal with them, it’s necessary to set various mocks and endpoints.

Moreover, teams need to struggle with the demands of the release management department, which often stops teams from launching their work before the main release. This causes coordination issues around the release plan, integration testing and the overall product. Once you deal with them, the market situation may change and your competition may grow. You might lose potential users.

Also, the release date of the product should be determined by market and product data; it should be based on business arguments. Organizational chaos undermines this and products are often released into random market situations.

Mistake 4: Creating many different backlogs for one product

Scaling Scrum can’t work well when you have one product and more than one backlog. Even with multiple teams, it’s always better to keep it simple and hold on to one product backlog. The rule of a thumb is this: for one product there should be one backlog and one product owner. The mistake of creating multiple backlogs comes from a need for teams to have separate task lists. That solution can however cause huge problems with prioritization. Teams would have to constantly change their current backlog priorities to stay aligned with each other. That almost never works.

The product backlog should be the one and only source of truth for all the teams involved in product development. Each of them should use the product backlog as the base line to create their own sprint backlogs.

You might be also interested in the article:

What’s the difference between a product backlog and a sprint backlog?

Mistake 5: Scaling Scrum in high-dependency conditions

You would think, with all departments trained and settled in an Agile culture, you are ready to scale Scrum. But that’s not always true. Imagine there is a team in your organization that can’t operate without previous actions taken by other teams. Even one team operating like that can cause troubles with scaling Scrum. As we mentioned earlier, incorrect structures, habits, and processes scale too. You don’t want that. Before scaling, try to minimize the number of dependencies between your teams or departments and prepare strategies to deal with them.

What is scaling Scrum? Final words

There are two aspects that must be balanced when scaling Scrum. First is learning and second is delivering. You can’t scale Scrum successfully without addressing either of these. Training and consulting are the best ways to start with Scrum scaling. Without it, you can end up with multiple Scrum teams delivering poor quality work in large amounts. To prevent this from happening, teach your teams Agile engineering practices. Make sure everything is in order and Agile values are adopted across the whole organization. Then (if you really have to) scale.