Reasons for not scaling Scrum

Ever since Scrum has become a staple "best practice" in software development, people have asked this same question: "How can we scale Scrum in our organization?"

Yes, Scrum can be successfully scaled. Yes, there are frameworks out there like Scrum-of-Scrums, SaFE,  LeSS. And there are companies which built up their very own framework, like Spotify.

Some work better, some not so well. But which one works for you?

Let me be a party pooper: None will - if you implement them as a prescriptive set of rules to deal with your organization.

Without being preposterous, I dare say that many organizations looking for a "Scaled Scrum solution" are asking for a solution without understanding what their problem actually is. And they become susceptible to the old adage, "A fool with a tool is still a fool".

 Here are some reasons why you should not scale Scrum in the first place:

Scrum Ceremonies break

• The Backlog grooming is an opportunity for the team to clarify what they need to know in order to implement a story. But how does the team clarify things where they are partially responsible - do they clarify together with those who are responsible for other parts? It is better to suffer the waste of receiving unnecessary information or to suffer potential lack of disinformation. So, you induce mandatory waste into the process.
• The Sprint Planning is the point where the team decides what they will work on during the next iteration. But since everything on the top of the backlog is high value high priority, scaling organizations also need to answer the "Which team does what - and why that team and not another?". It is an entirely new level of Sprint planning which is non-existant in a small scale implementation - and it is also inherent waste.

• After the Daily Scrum, you still have no idea what is going on and where the real problems are ... the main purposes: synchronizing and focussing, are not met - because you need to synchronize with people outside your team and others may focus on things you don't even care about! But how do you know - without yet another meeting where no working software is produced?
• The Sprint Review may not be between teams and customers - it often becomes an internal festival where developers show results to each other: Customer centricity becomes a tech talk. Maybe you need an "IT review" and a "Customer Review"?

• The Sprint Retrospective is specifically intended a place for the team to be amongst themselves. But what if the problem is bigger than one team? Who solves problems that are inherent to the organization, but not visible to any team? Who will address the elephant in the room?

Scrum Roles break

• The Product Owner should be steering the team to deliver maximum value. Once this turns into multiple teams, the availability of the PO to the team becomes an issue.  Antipatterns like the "absent PO" or "disempowered PO" become commonplace.  Manytimes, PO Consortiums or a PO line hierarchy arise. The problems between separating accountability and responsibility are obvious - they lead to bureaucracy and CYA - both dangerous to the product and the organization itself!
• The Scrum Master can't work like before.  All of a sudden, it's not about a team's impediments, but about the teams' impediments, so the conflict of interest "Our team vs. Greater Good", which the role was intended to resolve, actually becomes their main problem.

•  The Developers also can't work like before. In the past, they were empowered to do whatever they needed to do in order to make a better product, as long as the team approves. Well - that ends when other teams are working on the same product. They need to align not only within the team, but also across team boundaries, losing the essential freedom to maximize value while minimizing cost and risk.

Scrum artefacts break

•  The Product Backlog contains enough stories for the team to work on. However, it should always stay at a manageable size. Is 50 a manageable size? How about 100 or 200? Well, probably not. However, if you want properly sliced stories for 5 teams and each team can do 10 stories per sprint, you'll be ending up with the need to have roughly 150 properly sliced high priority stories in the backlog. Tell me what is important when you have 100 "high priority" items on the radar!
• The Scrum Board breaks, because one team's doesn't really tell us what is going on. You need to look at all teams' Scrum boards to get a grip. Unfortunately, the boards only tell a rudimentary tale. The real story is told in the Daily - and since you're not attending all the dailies, you can't understand what the boards are meant to convey.

•  The Velocity breaks, because each team has their own velocity. Either, teams will align estimates across teams or teams will have individual estimates on their own stories. In the prior case, teams have to abandon their former way of estimating. Previous estimates become an invalid basis for comparison.

• Release Planning breaks if velocity is broken because teams use individual estimates, the  PO will get completely confused because all of a sudden, Story Points  become team-dependent and not a valid capacity metric.

Communication breaks

Yeah, I know for many organizations, the Agile Manifesto is just a boring mandatory Power-Point slide at the beginning of the Scrum Training. But remember the first value? People and interactions over processes and tools.

• Bigger organizations sooner or later become so big that you don't know who knows or does what.

• When developers don't know who can help them on a specific issue, they are likely to implement a sub-optimal solution.   

• More people always means more communication. More communication means less time for implementing solutions.
  
  
• Chances are when communication time exceeds coding time, you would be more effective with less people.
• Reducing communication is not a solution: Keeping people ignorant or introducing Chinese Whispers will not make your product better.

Product Vision breaks

• As single Product Owner, you must be a superior, exceptional leader to align a scaling amount of stakeholders who all have their own objectives on your vision. If you are up to the task, maybe Presidency of a government would be more suitable than scaling a Scrum organization?

• If you work with a Product Owner Consortium, please take a minute and have every Product Owner explain their main objective to a neutral observer, then ask the neutral observer to describe the Product. Be prepared for a surprise!

Continuous Improvement breaks

• It's already not easy to fix something broken you have full control over.
• Now, try fixing something which is broken for you, but works for another team!
• Next, try fixing something which is broken for someone else, that affects what you do, but has been established by yet another team - without making anything worse for anyone!

Team autonomy breaks

• When teams lose the flexibility to fix their own problems, they slow down, morale and output drops.
• When teams lose control over their own work, being dragged into processes they do not want or need but that others want or need, they slow down, morale and output drops.
• When new people get onboarded, how will you deal with the team structure? You can't simply add new people to teams all the time, because a team of 20 doesn't work. 9 is already an overweight. You also can't rip teams apart, that will devastate productivity and morale. You also can't just put new people into a new team, because they don't get familiar with the existing Working Agreements unless they work in an existing team. So, any new person you add results in un-answered organizational questions.
   

Summary

I am not saying you can't scale Scrum. However, you should resist the temptation of scaling just because you think you should - chances are, you can't and don't know it yet. The consequences of scaling are severe and the cost of scaling may far outweigh the benefits.

It may be necessary to scale, but it is significantly better to avoid and postpone scaling as long as you can. Once it becomes inevitable, you need to be aware of the detrimental impacts - and deal with them before they destroy your scaled organization!

A LeSS course is a good way to get input how to solve the most common problems of scaling. But you can't take LeSS blindly and hope it will solve your problems for you. You still need to find out what works for you!