Hi and welcome to the Scaling Done Right podcast. This is the first episode and my name is Gereon Hermkes. Today we’re going to talk about why you need a scaling framework for Scrum, why you need to scale at all, what business agility is, and why scaling Scrum often fails.

So first of all, why do you need to scale Scrum? Well, you kind of don’t unless you have more than, let’s say, two or three Scrum teams. Something that we see all the time is that people come up to us at a meetup, at a conference, and they’ll say the following: “We started Scrum, it worked really, really well for us. Then we added a second team and it was still great. Then we added a third team, and suddenly something happened. We didn’t notice it at first, but the new teams didn’t offer as much as we had hoped they would. But even more insidiously, the teams that we already had started to slow down.”

Do you have an idea what that could be based on? The answer to that is simple: it’s a scaling framework that’s missing. If you have just one team or two teams, doing good Scrum is all you need. But as soon as you add more teams, if you keep on adding more teams, it’s going to get a lot more complicated. If those teams — let’s say five teams — act together as the release team, they work on the same product that they release, you need to have a scaling framework. Otherwise, you’re just going to create chaos. If you have cross-team dependencies, they need to be addressed. If you want to prioritize the work for 20 teams, you can’t achieve that with just normal Scrum. So you need a scaling framework as soon as you want to use Scrum in more than, let’s say, two or three teams.

There are actually levels to scaling Scrum. So if you have just one or two teams, like we just said, you can just use normal Scrum. And if you have a lower number of teams — let’s say five to eight — I think it’s okay to use any of the scaling frameworks that are out there. But if you really want to have true scalability — meaning, what if you have 2,000 teams like SAP does? What if you have more than 3,000 teams like Amazon does? How do you organize them? What scaling framework do you use then?

Here it is that I think Scrum@Scale really shines. You can actually add as many teams as you want, and the velocity — the productivity of the teams that you already have — will not go down. Any new team added is actually going to increase the productivity linearly, meaning you don’t have decreasing returns to scale. Decreasing returns to scale basically means if you add a team, if you add another team, overall productivity is going to go down. And that’s what happens with just using normal Scrum. You add a new team and suddenly your overall productivity goes down. In my view, that happens with other scaling frameworks. But Scrum@Scale allows you to scale linearly, meaning we have constant returns to scale — every team added adds its own velocity without slowing the overall system down. And this is really powerful. This is almost revolutionary. And it’s not very intuitive to grasp, but this is what it’s about.

What good does a scaling framework do if as soon as you add the ninth team, suddenly stuff starts to slow down?

In addition to being able to address a lot of teams — like in the hundreds — what Scrum@Scale also offers is Business Agility. And Business Agility basically means that you don’t have an organization that is maybe still Waterfall and you sprinkle a couple of teams at the bottom. The whole organization is actually using Scrum to operate. That’s why Scrum@Scale is sometimes called the Agile Operating System for a company — because everything in that company will be organized in an agile fashion using Scrum from the top management to the teams at the bottom of the org chart. And in truth, the org chart will not really exist anymore. You’re going to have a network of teams that work together.

So the question is: we’ve kind of talked about why you need to scale and you need to scale if you have more than a couple of teams. But why do you actually need to do Scrum? Why do you need to do scaled Scrum? And the answer for that is that — and I think everybody of us feels that — the world is changing too rapidly. If you just open the newspaper (and of course nobody opens the newspaper anymore because that also has changed), you can see the rate of change not only has increased tremendously, but it seems to be increasing every day.

We can see that in COVID, which is happening right now. We can see that in technological advancement. For example, GPT-3 just came out. If you have never heard of that, Google it, watch a YouTube video on it, and be shocked. Quantum computing is around the corner and everything just seems to be getting quicker and quicker and quicker.

And in this very chaotic world, you need to be just as — I don’t want to say chaotic — but just as flexible and humming at the same frequency, vibrating at the same frequency, so that you can actually react just as quickly. If the outside world is changing all the time and your ability as a company to change is very limited, then you’re going to have a lot of problems. Because we cannot control the outside world, it is imperative that we increase our ability to change, to learn, to adapt — basically to vibrate at a higher frequency so we can match that of the outside world.

By doing that, we can best our competitors. Every change in the environment is going to be an advantage because we can make use of that. TikTok comes up — we’re on TikTok, we’re growing with it. There’s some new regulation because of COVID — good, we can just adapt to that and take advantage of that. And so by adapting much more quickly, learning more quickly, we can best our competitors. But going even further, we can actually start changing that environment — just like Amazon is setting the pace, setting the expectations of what it means to, for example, do online shopping. They’re influencing the very environment that we’re living in.

If you are a manager, a high-level manager, and you’re thinking about “Well, that’s all nice but I still need to understand why I should do Scrum and especially Scrum@Scale,” it’s simple: look at the top companies, for example in the United States, by market capitalization. Think about which one of them are being agile. You’ll see that more than half of them are. And the truth is that companies, if they want to survive, cannot afford anymore not to be agile.

This is something that’s sometimes irking us as Scrum coaches because people sometimes still treat Agile as something new, something to be aspired to in the long term — maybe like a dream or like a vision. But the reality is, without it, your company is at risk of failing.

Yes, you might have some barriers of entry, some protective mechanisms because you’re partially state-owned, because you have a monopoly, maybe you have patents — and that’s all good, that’s true. But if you think about the empires, the companies, the organizations of the past, how many of them were invincible once and then fell? Think about the German car industry, how incredibly powerful they were just a couple of years ago. And now Tesla, which is basically run by a part-time CEO, is running circles around them.

So be very careful if you’re not agile — which most companies aren’t. Be very careful if you’re not agile, because the survivability of your company is probably at stake.

Why does scaling often fail? Well, there are a couple of reasons for that. One of the main reasons is that, like we discussed in the beginning, people don’t use the right scaling framework. They either don’t use one at all, they use ad hoc scaling, or they use one that’s limited to a couple of teams when they actually need one that can take them very far.

The other problem is that while a lot of people think that they’re doing good Scrum, they’re actually not. One of the core tenets of Scrum@Scale is: “If you cannot Scrum, you cannot scale.” Meaning, if your Scrum is already not that good in your first couple of teams and you try to scale, you will just magnify that inability to deliver on the team level. So it is very important to get good Scrum first and then scale. If you scale prematurely, you’re just going to be in a world of pain.

So wrapping up, I think it’s very important for you to understand that:

• You need to be agile as a company because your survival depends on it.

• Having good Scrum is imperative.

• You need to have good Scrum on the team level, otherwise you can’t scale.

• You also need to have a good scaling framework — one that is actually agile, not just in name — and one that allows you to scale beyond a couple of teams so you can actually achieve business agility and have the whole company operate in an agile fashion.

That’s one of the reasons why we think that Scrum@Scale is really the scaling framework to use. And I’m looking forward to the next episodes where we will go a little bit more into details about what Scrum@Scale is all about.

If you need any help with scaling Scrum — in the form of coaching, training, mentoring, whatever — don’t hesitate to reach out to us. You can reach me, Gereon Hermkes, at teamflow.de and you can reach Luis Cantilla at raskere.com — that’s r-a-s-k-e-r-e dot com.

Thank you for listening, and talk to you soon.