Get certified - Transform your world of work today


Scaling Scrum

The “what” and the “should we” problems

20 June 2017

Raul Herranz

I've heard some confusing talk about scaling Scrum. This is a critical problem, because scaling Scrum has become mainstream in the last few years. There are various frameworks and an equal number of opinions about them — some based on experience and others on assumptions and beliefs.

But let’s forget all that noise and think about the real meaning of scaling and what people mean when they talk about "scaling Scrum." In my experience, when people refer to scaling Scrum, they may be referring to any of the following different situations:
  • A Scrum Team that becomes bigger than the maximum size of nine development team members
  • A Scrum Team that is developing multiple products
  • A company that aims to become Agile as a whole by using Scrum
So let’s explore each of these situations a little bit more.

More than nine developers

When a development team grows to, or must be created with, more than the maximum size of nine members, as defined in the Scrum Guide, it seems like nobody doubts that some sort of scaling solution must be taken.

But for me, the problem (and I’m not going to discuss different scaling solutions) is that this increment of people working on the project may not be the best solution for the problem we want to resolve.

It’s easy to understand that this kind of solution (increasing the number of developers) may be pushed to resolve a problem with the capacity/velocity of the actual team. But it’s a solution based on old paradigms. So nowadays we could or should explore new ways of reaching the desired velocity, such as working harder on removing the impediments of the team; improving task automation; improving the team members' skills and knowledge; and improving the cohesion, motivation, and communication of the team. And those new ways of improving the capacity/velocity of the development team won’t come with the problems associated with increasing the team size, such as lack of a shared vision, bad communication, or synchronization problems.

Developing multiple products

I have to admit that I don’t know if this is a common problem globally, but in my Scrum trainings in Spain, and also with some of my clients as an Agile coach, I’ve faced the same question: How does Scrum apply to a single team developing multiple products? The answer is easy. This is a scaling problem. Therefore, we have to deal with it from this point of view. And what I can add is that, regarding all the problems that you may find, you have to focus on dealing with the lack of focus!

Really? A scaling problem? Of course. Understand that you are going to work with a single development team that is working with multiple product backlogs that indeed may be managed by different product owners. So instead of scaling the development team, what we are scaling is the role of the product owner, or we are scaling the idea of product ownership.

I think that this is not the best solution, and in the end we should have different development teams for each of the different products. But I have seen that most of the times this is not something easy to get done in the short or even medium run. Maybe a scaling approach is not the worst solution.

A whole company becoming Agile

I have my questions about what an Agile company is supposed to look like. Even when I’m working in Agilar, a Teal company, I am not always sure that this is a valid model for every organization in the world or that this is the only valid Agile company model. In fact, what I am discovering by working with my clients is that thinking about changing the whole organization from the very first moment is not always the best idea, especially when we are working with such big companies with a strong Taylorist culture.

So why do some consultants and frameworks try to sell us the idea that big companies can or may change as a whole? Easy. They have seen that there is a niche market of large companies who want to surf the Agile wave, and they want to make money. But applying those frameworks is hardly going to be enough to change the organizational culture from a Taylorist to an Agile mindset.


In this article, I’m talking from a theoretical point of view based on my learnings after several years working with different organizations. The real answers (maybe different answers each time) will appear in real-world situations we are facing every day at our organizations or working with our clients.

What I can say for sure is that each of these different situations, which everybody thought would require a scaling Scrum approach, must be treated according to its individual circumstances. When facing these situations, we must understand our goal and question whether scaling is in fact the best option. Only after this careful consideration, and if we do decide that scaling Scrum is the best option, will we be able to decide which scaling approach will best fit our needs.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (5 ratings)


Samuel Casanova Romero, CSM, 6/20/2017 4:33:33 AM
We can apply the Pareto principle to explain why scaling won't be the best solution in the majority of situations: As only 20% of you do produces 80% of results (the rest is mostly waste), with an increase of 100% of resources on your team you will only get a 20% of value increase". Now maybe you want to focus on other much more efficient solutions like removing impediments, task automation, improving skills, cohesion, communication, motivation, etc.
Tim Baffa, CSM, 6/20/2017 4:26:35 PM

I'm unclear about the intent of your article in regards to misuse of "scaling".

Your first example talks about large teams and management tendencies to throw additional members on a team with the intent of reaching goals. That has nothing to do with scaling. That is simply management failing to understand the negative productivity effects with adding people to a team/project.

I would ask in your second example why scaling is an answer to a single team working on multiple products. That approach is incorrect Scrum, and the solution, from the Scrum Guide, is to ensure that each Development Team is working with a single Product Owner. That has nothing to do with "scaling".

Your third example briefly talks about how scaling is used to address large-scale organizational adoption. I would simply question why anyone would believe such a significant cultural and process change could be addressed by "scaling".

I'm also quite surprised that an Agile Coach would misunderstand the purpose of team velocity as a goal, and not what it really is, which is a reflective metric to aid planning.

And in NO way should an Agile Coach even suggest that a team try to achieve a desired velocity by "working harder".

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up