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.