Hello and welcome to the second episode of the Scaling Done Right podcast. My name is Gereon Hermkes, and this podcast is about scaling Scrum with Scrum@Scale. It closely follows and kind of supports the book that Luiz Quintela and I have written, which is called Scaling Done Right: How to Achieve Business Agility with Scrum@Scale and Make the Competition Irrelevant.

Today we’re going to look at the second chapter, and specifically we want to talk a little bit more about what makes Scrum@Scale really special.

One thing that we often see when we are doing Scrum@Scale classes is that people really overestimate their ability to do Scrum on a team level. This sometimes leads to a very interesting situation in the class because at the beginning of the Scrum@Scale class, we repeat the Scrum basics. That is a strange situation because you’re actually required to have some Scrum knowledge before you take the Scrum@Scale class. It’s not enforced, but the expectation is clearly communicated that you have to know Scrum before you come to a Scrum@Scale class.

With that being said, people then sometimes get upset because they say, “Well, I’ve paid a lot of money for this advanced class, and why are we doing the basics again?” The fact of the matter is that the basics usually aren’t as well entrenched in most people as they think. This usually becomes apparent if you play one of the games — for example, Kahoot, that nice online game that everybody can play with their cell phone. That’s cool. Or if you do another version of that where you have people draw a visual map of Scrum to reflect on their knowledge, bring it out so everybody can see it, and then present it to the group.

As soon as you do that, you immediately see that people realize, “Well actually, I thought I understood Scrum, but I don’t know it well enough.” The reason why that is so important for us is that if you can Scrum, you can scale — that’s a quote by Dr. Sutherland, and it’s really, really important. If you don’t do Scrum well on the team level, then scaling it will just multiply your problems. If you don’t take anything away from this podcast or the book, please take that away.

There’s also an opposite of this that is true, and we’re calling it “If you can scale, you can Scrum.” What do we mean by that? Basically, we’re saying that it’s great if you know how to do Scrum on a team level. Not a lot of people actually know how to do that — to have really high-performing teams — so that is very commendable, and we salute you. But in a sense, we are saying that the game has changed. If 10 years ago, 15 years ago, 20 years ago, you did good Scrum on a team level, you were the man, you were the woman, you were it because you were able to have a team perform on a very high level.

Today, the game has changed. Today, if you want to compete successfully, what you have to do is you have to be able to have the whole company run with Scrum, having the whole organization be agile. If you just have good team-level Scrum, that’s kind of not enough anymore because you will be eaten alive by competitors who actually achieve business agility.

So yes, it’s true — if you cannot Scrum, you cannot scale. But the opposite is also true: if you cannot scale, well, sure, you’re doing Scrum on a team level, but the game has changed, and you need to improve your game. Meaning you need to learn how to Scrum@Scale in order to remain competitive.

When organizations are struggling with implementing company-wide Scrum, there are usually three areas of specific interest that represent the biggest problems.

The first is prioritization. Prioritization is everywhere, and it’s always a problem. The funny thing is that a lot of managers expect the teams to prioritize correctly — meaning the Product Owner does the prioritization and the whole team prioritizes effectively. But when you talk to top executives, it’s not unusual to see them trying to accomplish 200 strategic initiatives at a time, or 2,000, or 4,000 products. So this problem of prioritization that we have in Scrum is also a problem at scale. But now it’s not the Product Owner who has to take care of it — it’s top management, and somehow this needs to be addressed.

The second issue that rears its head in scaling is delivering a working product. You might think, “Well, this is the same in Scrum,” and yes — actually delivering something and not just producing something that is almost done is what all of this is about. But it becomes much more complicated at a scaled level because then you have to integrate the work of numerous teams. The coordination effort and the level of difficulty are just that much higher.

Lastly, one area that is very important to us — and that’s why we also call these issues the Mega Issues instead of organizational refactoring — is adapting the organization to changes in its environment. If something changes, we want to be able to adapt the whole organization to that change. That might mean taking a couple of Scrum teams from one product and moving them over to another one, and we want to do that fairly quickly. We understand, of course, that people might have to relearn skills and it will take some time — it’s not something that can happen immediately. But what we don’t want is for organizations to remain frozen despite obvious changes happening — and remaining so for a couple of years, which is something I think every one of us has seen in the past.

You look at an organization and it doesn’t make any sense, and when you ask why it is that way, the answer is, “Well, in our history back then, 20 years ago, this happened.” And you’re thinking, “Well, that was 20 years ago. So much has changed. Isn’t it about time that you change the organization?” This is something we want to address — we want to be able to adapt the organization more rapidly so that teams can work on the stuff that brings the most value for the company, that makes the biggest impact.

In Episode 1, we talked a little bit about the different levels of scaling, and I already mentioned that you need a scaling framework that can actually encompass the whole company. It’s not enough if you can just manage a couple of teams that work together on one product. You want a scaling framework that can coordinate the whole company.

There is something to be aware of, however: sometimes scaling frameworks just purport to be about business agility. They say, “Oh well, we’re very agile. We have the teams at the bottom, and then we give you something to coordinate those teams, to steer those teams.” It’s very important that while it’s good that they have something for the business agility part, you need to check and make sure — verify — that you’re actually still doing Scrum or Agile in general at the top level. Because if you’re just taking Waterfall project management and then sprinkling some Scrum teams at the bottom, you’re not really going to achieve business agility. Quite the opposite.

The teams will be doing Scrum. They will be increasing their velocity. But if the rest of the organization isn’t doing Scrum, they’re going to be slowed down by that organization again. You’re basically starting a transformation and will kind of be stuck in that transformation forever. So be very careful what kind of scaling framework you choose.

What we think makes Scrum@Scale very different is our focus on the MVB — Minimum Viable Bureaucracy. That means we try to reduce bureaucracy to the absolute minimum. Bureaucracy per se isn’t anything negative — it’s something we need — but it also has the unfortunate tendency of multiplying until it takes the organization over and grinds it to a halt. So we want to focus on keeping it to the absolute minimum.

The reason why we want to do this is because we want to keep decision latency low. Decision latency is a term that refers to, let’s say, a team member asking for a decision. It could be very simple — like, “I have a button on this website. Should it be green or orange?” As soon as that question is posed by the team member, how long does it take for the decision to come back from the Product Owner, for example?

If they’re all sitting in a room, if they’re doing Scrum, the team member will speak up and say, “Product Owner, should it be orange or green?” and the Product Owner will say, “Orange.” It will take two minutes — and that’s the decision latency.

In more traditional companies, what happens then is — it’s a simple question — but there is no Product Owner. And if there is something similar, that person will not be empowered to actually make decisions. So then that question has to go up the chain of command, up the hierarchy. It will go up for a couple of levels on the org chart and then it will probably cross into another functional silo — maybe where design or marketing is concerned. So it goes up a couple of levels, crosses the boundary, and now we’re in Marketing, Design, PR, whatever. Then it goes down the org chart again until you find the person that can actually say something to that.

This takes a lot of time — it goes up and down the org chart, and the answer comes back in 14 days. You can already see that this won’t work. You need to have low latency in order to actually be agile. We think this is of paramount importance in Scrum@Scale.

Now comes something that’s a bit unintuitive but super interesting: how do we achieve that low decision latency? We do that by mimicking nature — by mimicking the fractal properties that we can see in many things in nature, for example in ice crystals, in blood vessels, in tributaries to rivers. There are a lot of situations where you can see that. And interestingly enough, one of them is the construction of the Internet.

If you think of the Internet, what makes it special is that it’s very decentralized. There’s no real central command and control hub. There’s no Pentagon, no single institution somewhere in a bunker that is the head of the Internet. As soon as you would turn that off, the Internet would go down — and that’s the whole point behind the Internet: decentralization as much as possible.

In practice, that means that every node should look like another node. Meaning we have a Scrum team, we have another Scrum team, and it all looks the same. If you have a couple of Scrum teams that work together well, they kind of form a bigger Scrum team. So we don’t really have org charts anymore in Scrum@Scale.

If you were to look at a graphical representation of a company that is using Scrum@Scale, you could zoom in and zoom out on that org chart and it would just look like Scrum teams — similar to zooming in on broccoli. If you zoom in on it because of the fractals, it will look the same. You can zoom in as much as you want, and it will still look the same as if you’re zoomed out. If you’ve never seen this before, please Google fractals and look at a couple of images or watch a short video on YouTube — it’s super interesting.

This is what we’re trying to mimic in Scrum@Scale, and that is what allows us to scale freely — to go in and out, zoom in and out, and add more teams without actually slowing down. The Internet isn’t slowing down if you add a couple more servers. The Internet is going as quickly as it does irrespective of how many servers, connections, or users you add to it.

This is maybe the most incredible part about Scrum@Scale and something that’s not very intuitive. It helps to take a class to really understand this. I’ll admit it — at first, I didn’t get it. It took me a while to really appreciate the magnitude of what that represents.

Think about it this way: in economics, there’s a concept of returns to scale. Basically, that means if you have a couple of inputs and you double them, you expect something to happen with the outputs.

For example, imagine you have a machine that’s producing drones and you have one worker to work it. Business is going well, and your output is 20 drones. Let’s say one machine and one worker produce 20 drones. Now one worker isn’t enough anymore to satisfy demand, so you buy a second machine — exactly the same machine — and let’s say to make it easy that you hire the twin brother of the first machinist. The machine is highly standardized, it’s the twin brother, they’ve done everything the same way, they have the same skill. If one machine and one worker are producing 20 drones, what would you expect to be the result of two workers and two machines? Probably 40 drones.

It might be a bit more, it might be a bit less depending on if the new machinist has some good ideas to increase velocity, or maybe he has a bad day, or picked up a bad habit that makes him work a little bit slower than the other one. But on average, you would say it should probably be double.

Now imagine you are the boss of a large corporation of 300,000 employees, and we tell you that because there’s a great opportunity, you have to double your workforce to 600,000. What do you expect the result to be? You’ll get everything you need — capital, the ability to hire that many people, everything is fine. We’re just looking at the fact: can you coordinate that many people?

Do you expect to coordinate 600,000 people just as well as 300,000 and get the same results? Probably not. Why? Because you’re not scaling linearly. Because you’re not like the Internet, where you can just add more servers, more connections, more users, and it’ll grow linearly. You’re probably looking at decreasing returns to scale, meaning that every worker and every machine that you add is going to bring more output, but it’s going to be a little bit less than the one before. This is something that almost all large organizations see.

You probably had a visceral feeling when I talked about doubling 300,000 workers to 600,000. You probably felt: “Well, this is unmanageable.” Which it is.

However, during the pandemic of 2020, Amazon added about 200,000 employees. Do we expect them to slow down? Probably not — because they’re doing exactly this. They are scaling linearly because they don’t allow bureaucracy, because they don’t allow central coordination nodes.

This is what we’re attempting to do as well. We want to scale linearly. We want to have constant returns to scale, so every team that we add to the company is expected to pull its own weight and not slow down the teams that have come before it either.

As I said, this is a little bit unintuitive. You have to wrap your head around it, and you have to realize how urgent the problem actually is in large organizations to understand why it’s necessary to do it a little bit differently.

But if you need a scaling framework for Scrum, you need to find something that scales linearly. Because otherwise, you’re going to run into the problem that every additional team is just going to slow the company down and not contribute as much as the team that came before it.

Alright, that’s it for this episode. Thank you for listening. You can find our book Scaling Done Right wherever you usually buy books. And if you need some help with your transformation — if you need coaching, training, mentoring, whatever — you can find me, Gereon Hermkes, at teamflow.de. You can find Luiz Quintela at raskere.com — that’s r-a-s-k-e-r-e dot com.

Thank you, and until next time.