Scrum Doesn’t Scale! Really?

“If you think you can, or you think you can’t – you’re right.” – Henry Ford

Over the past several years, I have heard agile experts claim Scrum does not scale. Many of these experts never really address why they believe Scrum does not scale. Instead, they usually spend their time talking about their own homegrown process—a process that according to them does, in fact, scale.

Anyone who is familiar with my articles knows that I am not one to get into process wars. My intention in writing this article is to discuss why I believe Scrum does scale and to highlight ways in which I have used it on medium to large enterprise projects where multiple teams were geographically disbursed throughout the US and other countries.

Before I go any further, I would like to review the team concept used when a project uses Scrum as its process framework. Ideally, each team will consist of a Product Owner, Scrum Master, and approximately 6 to 8 other people who have the ability to contribute to the successful completion of the User Stories; this could include software application/solution architects, developers, UX designers, testers, infrastructure engineers, etc. These teams can be focused on creating supporting components, features, etc. They can also be responsible for the vertical or horizontal aspects of User Stories.

I would also like to define the term scale. In this case, scale means that there is more than one team working on the same project at the same time. You would normally see this happening on a medium to large sized effort that requires more than one team working in parallel.

I first heard the statement, “Scrum does not scale,” from a colleague who was teaching me a company homegrown version of an “agile” process. By that point in my career, I had read numerous books about Scrum and had actually worked on several small projects that had incorporated Scrum as their software development management process; however, I did not have the opportunity to experience it on a large-scale enterprise-wide effort. Thus began my personal quest to see why not only my colleague but several other people who I knew and respected believed Scrum did not scale.

After spending a great deal of time and effort scouring the internet and reading books and articles written by many notable Scrum experts, like Ken Schwaber, Mike Cohn, and Ken Rubin, just to name a few, I came to the conclusion that Scrum could scale. The question as to why some people still believe it cannot scale will have to be left for another day.

When faced with a situation, such as this, that challenges a process I am learning, I tend to revert to the lessons I learned in my former life as a Non-Commissioned Officer (NCO) in the U.S. military. I was in the United States Marine Corps from 1971 – 1976 and the U.S. Army from 1976 – 1992. As you can imagine, I was well indoctrinated into doing things a certain way. For over twenty years, I worked with small teams; and the success and/or failure of the missions of those teams was dependent, in large part, on scaling.

Here is a quick primer for those that have never served in the military and do not understand the structure. Generally, the organizational structure of an Army consists of the following:

Army Organizational Structure

Army Organizational Structure

Let’s break down the structure and add some leadership roles:
Fire teams: 1 team lead + 2 – 3 people
Squads: 1 squad leader + 3 – 4 fire teams
Platoon: 1 Platoon Leader, 1 Platoon Sergeant, 3 – 4 Squads
Company: 1 Company Commander, 1 First Sergeant, 3 – 4 Platoons
Battalion: 1 Battalion Commander, 1 Sergeant Major, 3 – 5 Companies

I am sure you get the idea, so I will not go above the Battalion level. I would challenge anyone who says the military does not scale. The military perfected the concept of small teams working in parallel a long time ago. You might be asking, “What’s this got to do with scaling Scrum?” Everything!

In his book, Succeeding with Scrum, Mike Cohn devotes an entire chapter on scaling Scrum. Another outstanding reference on this topic is in Ken Rubin’s book, Essential Scrum. Both of these authors do a far better job explaining the details of scaling Scrum than I could. As my goal is not to teach you how to scale Scrum, but to show how I successfully scaled Scrum on my own projects, I will not reiterate their insightful information. If you are interested in learning more about scaling Scrum, or anything related to Scrum, for that matter, I would encourage you to read these books.

When doing any type of scaling, it is important to understand that team members come and go; people quit, are fired, go on vacation, get sick, etc. We deal with these scenarios on a daily basis. Therefore, it is imperative that the structure of the team be fluid and that it allows for worst-case scenarios. When I am building a team, I keep this in mind; and I make sure that no single person is indispensable. Cross training is vital. Ken Schwaber recommends that development teams be cross-functional.

Team size is also important. Communication problems increase with increased team size, as do coordination issues. Back to the military analogy, the smallest team in an infantry company is usually the fire team; it usually consists of 3 – 4 members. Each member has a basic skillset as an infantryman, yet they may also have additional skills such as machine gunner, grenadier, etc. A fire team can accomplish several small missions within the overall objective; however, they must maintain regular contact with the other elements so they can coordinate their effort towards the bigger mission.

The same is true with the development teams that I work with. I keep them small enough to enable good communication and yet have sufficient numbers to accomplish the tasks. For me, anything greater than 8 people starts to exceed the team size that I prefer. I have gone as high as 13, but that was really pushing my comfort zone.

Once I’ve gotten the teams put together, the other pressing organizational challenge is the role of Product Owner. Some of my clients have been very resistant to a dedicated Product Owner for every development team, and I get that. In order to accommodate the client and still meet the needs of the development teams, I can usually get the client to agree to have Product Owner Proxies.

Product Owner Proxies are individuals who have been empowered to act in the Product Owner’s stead when he/she is not available. The Product Owner is still ultimately responsible for any decisions that are made, so it is imperative that he/she trust the proxy. It is also vitally important that the Product Owner does not constantly contradict the decisions of the proxy, as this defeats the purpose and diminishes the effectiveness of the proxy.

In regards to multiple Product Owners, teams of Product Owners, and even Chief Product Owners I will defer to Ken Rubin’s book, Essential Scrum. Ken does a great job detailing these structures.

Of course, forming the teams is only part of the scaling effort. The crucial component is the adoption and coordination of a communication chain. Communication does not simply involve having constant meetings; it also involves coordination and acting on the results of the communication. In order for communication to be effective, the right people must attend the right meetings. It is also imperative that all needed information is disseminated ahead of time and that it is correct.

Useless and non-productive meetings can overwhelm staff and cost companies millions, if not billions, of dollars. I have been involved in far too many efforts where everyone is invited to attend every meeting, and the communication plan looks like this:

Communication Overload

Communication Overload

This graphic, taken from Ken Rubin’s book, Essential Scrum, is an example of communication overload. We all know what happens when there are too many cooks in the kitchen; nothing gets done—and if something does get done, you can pretty much guarantee that it is going to be a mess. I believe the way to solve this problem is found in the Agile Manifesto: teams are self-organizing; therefore, wouldn’t it be appropriate to allow the teams to coordinate communication amongst themselves. We do not need to interject any other form of management to handle the coordination of the communication.

Self-organizing teams work with other self-organizing teams in order to determine dependencies, priorities, special skill requirements, etc. Some of this coordination can be done in the Scrum of Scrum meetings, where a member of each team comes together and discusses what has been going on with his/her team. Other discussions and/or meetings can be conducted as needed. Problems and misunderstandings arise when people read the Scrum Guide, only see the recommended list of planning sessions, and declare that Scrum does not allow for any other type of meetings – Poppycock!

In Essential Scrum, Ken Rubin discusses the concept of inter-team communication and explains how teams can form what he calls communication clusters; see the below figure as an example.


Communication Clusters

Communication Clusters

Communicating across numerous teams is at the best of times difficult. However, it is doable provided we take the time to discuss the situation and allow the teams themselves to self-organize and work through the various channels of communication. Effective communication will bring about overall collaboration.

As stated earlier, Scrum does scale. I know because I have done it through enabling effective communication and overall collaboration between self-organized teams.



This entry was posted in agile. Bookmark the permalink.

2 Responses to Scrum Doesn’t Scale! Really?

  1. Tony Zeoli says:

    Thanks for sharing your view in scaling agile/scrum. I’ve been workin in this methodology for almost two years now and having gone through some coaching as well as having networking skills, I can see where communication breakdown can affect the entire process. It’s so important to be talking constantly – not to the detriment of the project, but with as much transparency as possible. My issue is that sometimes people who don’t know agile then buy into the idea, but fall into old habits of control and that’s where it breaks down. Once a few people on the team decide to not commit or they don’t even really get their responsibilties, things become much more difficult when if they just followed the process, success would reveal itself through a shared commitment.

    I am reading the book you’ve linked to here, so I’m glad I’m following along with the right tools.


    • Steve Crago says:

      I truly appreciate your comments. I’ve been exactly where you are at, unfortunately more times than not. It takes perseverance, patience, and getting to the root of the real problem. I also recommend Lyssa Adkins book “Coaching Agile Teams” and Jean Tabaka’s book “Collaboration Explained.”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s