Scrum Doesn’t Work for Big Companies. How True Is That?

Understanding how Scrum varies for different size companies.

Scrum isn’t scalable. Whenever I hear that, I feel a strong punch in my guts. This perception is becoming more common; too many people doubt Scrum can work in organizations with dozens or hundreds of teams. Within this assumption, they long for scaled Agile frameworks. And from there they go straight to the waterfall mindset. 

Is it true that Scrum doesn’t work for more than a handful of teams?

Do organizations have no choice but to use a scaled (fake) Agile framework?

What’s the difference between Scrum with one, ten, and a hundred teams?

Teams will be trapped or empowered depending on how you answer these questions. I’ve experienced both sides of the coin and learned what leads to traps or empowerment. 

Let me share what I learned about the differences between Scrum in different organization sizes, how to scale it properly, and the common traps that lie ahead.

Everything Starts with Solid Foundations

Some time ago, I had the pleasure of joining an early-stage start-up. We were small and had opted to use Scrum. Our objective was clear: prove market fit. But time wasn’t on our side. With a seed investment, we had limited time to convince more investors to fund us, or we’d run out of money. 

Our Scrum team was cross-functional, as we had all the required disciplines to create value in every Sprint. I won’t lie to you. We screwed several Sprints before figuring out how to function as a team. After that, we were in the flow. Sprint after Sprint, we got better, and our output resonated with clients and created valuable outcomes. How did we get to this stage? I better tell you what slowed us down first:

• Too much attention to how: In the beginning, we were just a group of people working together, not a team. We put our attention into “how” questions. We strived to have better Sprint planning, refinements, Sprint reviews, and so on. The result was mediocre. We made irrelevant improvements and didn’t get any better as a team.
• Trying to “do” Scrum better: We perceived Scrum as a set of events, artifacts, and roles. We were adamant about that. We called each other out when we slid away from the Scrum Guide. Again, it wasn’t helpful.
• Roles and responsibilities: Each role had clear boundaries, and we did our best to respect that and not cross any line. We ended up messing up everything and having pointless discussions.

At some point, we started caring less about Scrum and more about how we collaborated. The a-ha moment came out of the blue: Our COO entered the room and wrote five words on the board, which I will never forget. Those words became our guiding principle in everything we did. It was exactly what we needed to put us back on track.

The words written by our COO were the Scrum Values. He wrote them because he found the values meaningful and sensed we were ignoring them.

Commitment, Focus, Openness, Respect, and Courage

Our takeaway was clear: Set solid foundations, and then the other parts will flow naturally and better. Do it any other way and you’ll end up running in circles and frustrated.

Single Team : Perfect World

When you have a single team, everything is simple. You don’t have to worry about dependencies, communication, or responsibilities. Everything happens inside the same team. The main worry you should have is having the foundations right. 

If your attention goes too much into processes, your team won’t make the most of Scrum. But when you set solid foundations, the team can steadily create value.

With a single team, your energy will go to the product. Solving any problem is quick because everything happens within one team. The critical aspect is setting a meaningful partnership with stakeholders instead of building a service provider relationship.

I tend to say that a single team is a perfect world. At this stage you know everyone well, which makes everything easier. Still, you have limited capacity, and if the business goes well it won’t take long until you have to scale and more considerable challenges arise.

Three Team: We Know Our Differences

Scaling is inevitable for a successful business, but doing it well is tricky. Most companies struggle to scale their teams properly. This is generally the moment our minds shift back to old ways of working.

Coming back to my initial example: After proving the market fit for our business idea, investors poured money, and we had to scale. The first step was to define how to do it, and I’m glad I was part of all of these discussions. Our business was B2B2C, and our one team was responsible for all audiences: buyers and sellers. To scale correctly, we enumerated vital aspects:

• Business outcome: Define which business outcome the team pursues.
• End-to-end responsibilities: Ensure the team is empowered from end to end to drive desired business outcome.
• Autonomy: Reduce to minimum dependencies between teams.
• Focus: Each team should know what to say yes or no to. Decision-making should be simple and fast.

We decided to slice the teams per audience—buyers, sellers, and back-office. Each team would be fully responsible from end to end for their audience and receive the desired business outcome to drive. This decision turned out to be the right one for us. We could still move fast and solve most of the challenges independently. It was easy to handle dependencies, as we still knew everyone.

Scrum served us well, and we didn’t add anything special to make it work. Our goal was to remain as close as possible to our initial setup. With three empowered teams dedicated to driving outcomes, we could help the business grow fast. The adventure was still pleasurable and engaging.

Ten Teams: Blame Game

The more the company grows, the easier it is for things to get ugly. When you get to the point of double digit teams, it becomes a challenge to get scaling right. Companies think they need help, and it’s time for a scaling framework. I’d recommend not doing that. I’ve observed better results when teams scale and address scaling problems as they happen instead of trying to create several processes to prevent problems that may never happen.

In summary, do your best to remain simple. Otherwise, a blame game will take over.

In one of the e-commerces I worked on, each team was responsible for a component or set of components. The setup created many dependencies by design. Almost everything in our roadmaps required the collaboration of multiple teams. Unsurprisingly, everything started out well, and suddenly stalled. It became a blame game. Many initiatives started, and seldom did anything get finished.

The scenario above is an example of how not to scale with Scrum. I could say that Scrum failed us, but in reality, we failed at scaling. In another e-commerce, we had a different approach to scaling with Scrum.

• Outcome: Each team drives the desired business outcome
• Experience: End-to-end responsibility of a single experience. For example, product search, product discovery, retention, etc.
• Scrum of Scrums: At the beginning of every Sprint, one team member attended a ritual to share what the team would focus on and if they needed support from another team.
• All Hands: Everyone from all twelve teams attended an all-hands meeting to know what each team aimed to achieve during that Sprint. This lasted around 20 to 30 minutes and ensured transparency, and it happened right after all teams were done with their Sprint planning.
• Product Alignment: Product Managers had weekly exchanges to align on the overall outcomes and how we progressed.

This experience was a different story compared to the previous one I shared. In this case, Scrum didn’t fail us. I guess we just learned how to use it. The atmosphere was engaging, and the teams supported each other. I wouldn’t say everything went smoothly all the time. We had hiccups—but could always handle them without blaming each other.

A Hundred Teams: Who Are You?

What about organizations with hundreds of teams? That’s a horse of a different color. It’s impossible to know everyone who works in every single team; dependencies become technically inevitable, and collaboration can easily fall into siloes. How can Scrum work in such setups?

You may be reading this and wondering, “Scrum won’t work. You must use SAFe, LeSS, or something else but not Scrum.” I feel you. Scaling beyond a certain threshold is demanding, but I must tell you that using frameworks like SAFe (undercover waterfall agent) will destroy your agility and create unwanted results. Before picking any scaling framework, think about the issues you must address:

• Transparency: How will teams know what each one is working on and avoid duplicated work?
• Communication: How will teams communicate with each other without overwhelming them and still being aware of relevant information?
• Dependencies: How will teams reduce dependencies and deal with the ones that do occur?
• Responsibilities: How will teams be accountable for end-to-end results?

The above questions must be answered before you start scaling. Scrum alone might not be enough, but that doesn’t mean you have to deploy a scaled framework immediately. I’d recommend embracing a journey and learning on the go. You can be surprised at how your teams can overcome problems when empowered.

My recommendation for large organizations: 

• Strive for autonomy as much as possible
• Benefit from sets of ten teams, as described before, that will allow those teams to collaborate naturally and create value faster
• Limit the number of roles to a minimum
• Do not separate discovery from delivery
• Ensure each team has end-to-end responsibility

With large organizations, you will face complexity and may try adding more of it. Don’t focus on complexity. Simplicity is your best ally.

Final Thoughts 

Scrum comes in different flavors, depending on your organization’s size. However, a key aspect is how you play the game. No matter how big your organization is, if you stick to the values and core of Scrum, you have a greater chance at success. 

The more you focus on processes to avoid errors, the less you can benefit from agility.

Strive to set an environment where teams are empowered to create value and feel trusted to make decisions. The results will be excellent no matter the size of your organization.

You may think Scrum doesn’t work in large organizations. I thought so too. But after some time, I learned that Scrum didn’t work because of how we played the game. Once we learned to play it differently, Scrum could serve our teams very well. Many times the problem isn’t with the game, but with the players.