How Scrum Can Go Wrong in Large Organizations

When I was involved in implementing Scrum in a waterfall-managed company, the available literature and knowledge was limited. The Agile manifesto was still relatively new, and there were few Scrum courses. There weren’t many frameworks showing how to coordinate and align more than 10 Scrum teams. 

So for the issues we had to solve, we had to rely on common sense, trying different approaches, and creating a strong feedback loop that would quickly tell us what wasn’t working. 

Our main approach was to slice up the product into different parts. The company was doing ecommerce, so it was quite easy to do. The main KPI in ecommerce is the conversion rate.

We sliced up the product based on different parts of the customer journey funnel. Several Scrum teams were responsible for the first stage of the funnel, others for the second, and so on. 

Every layer had business goals. The first layer was responsible for visitors converting to add items to cart, another for sign-ups, etc.

The cool thing was that the final layer included a KPI regarding returning customers. It created a nice loop of the funnel, which seems crucial to me.

Every layer of Scrum teams had its own KPI to grow using their own resources, and making their own decisions.

These were just the Scrum teams responsible for visible, predictable things. Another group of teams were responsible for the platform, communication between services and modules, tools for developers, all the things that make the business work in the background.

All in all, the 20 teams covered all internal and external needs of the organization.

How do you diagnose the problem of misalignment between so many Scrum teams?

Once we started seeing different features that the teams were developing, we realized that some of them contradicted others. Team A was building one thing, and hoping to achieve a goal that was quite opposite to what Team B was trying to achieve.

The main, big solution to this is to define, create and promote the strategy of the company within the organization. 

Everyday, in every company, thousands of decisions are made, from tiny to huge. If your team lacks a common understanding of what the main company goal is, those decisions can contradict each other, leading to lower impact on both sides. 

A clearly defined strategy solves this. It tells everyone why we’re here, what’s the role of every department and person in the grand scheme of things, why and what should be delivered to the customer or stakeholders—or “internal clients” as it’s sometimes called in the enterprise world.

Once everyone knew what should be done and why, the second step we took was something that might sound weird. In a big organization, Product Owners shouldn’t have full autonomy to decide what to do. Let’s not beat around the bush—we needed them to obey, to a certain extent, the decisions that were made higher up. 

But it’s not as simple as imposing your will on people, you don’t want to be a total authoritarian. What we came up with was to match the teams in groups, and introduce a new person that would be a bridge between them. Someone responsible for a group of teams, who would coordinate, and control how they spent money and time in every sprint.

We called them Product Development Managers, and each one was responsible for one layer of the customer journey funnel, along with the teams that were inside that layer. It seemed reasonable at the time, and it worked really well for us.

But it’s not the only solution. There’s one that’s more general, one that drives efficiency in individual Scrum teams, and between separate teams: the feedback loop.

You might introduce a strategy and new roles within your company, but without a feedback mechanism, you won’t know if it’s working.

We set up our main goals by defining our place and share in our market. We had to measure ourselves against the competition, see what our advantages and disadvantages were. But it’s not enough to do it once, it needs to be done regularly.

In our case, there was a big strategy update once a year, but now I would advise to do revisions at least every 6 months. It will tell you if you’re still on the right track, and show you if your decisions are still valid and beneficial for the company. Valid in terms of how the market and competition are changing. 

The impact of COVID on the ecommerce industry is a good example. The market changed rapidly and unexpectedly, and companies threatened by this situation had to adapt or die. Especially offline companies, which had to quickly undergo digital transformation in order to survive.

How can you learn and adapt to market circumstances quickly?

Your company culture shouldn’t support failures, but it should tolerate them. The feedback loop makes this possible. 

Every mistake should bring us to lessons, and to new ways of eliminating those mistakes, new approaches.

It’s not about celebrating mistakes, but talking about them openly. Analyzing why they happened, what should be done differently.

You need to give mistakes the right amount of attention and make sure they’re easy to discover.

It’s really hard for managers to provide information about mistakes without placing blame, without pointing fingers at the people or teams who made the mistake.

Being honest, fair and transparent is crucial. Post-mortem documents can be created, and spread across the organization if there was a failure, so everybody knows what happened and how to avoid it in the future.

Let’s move on to a few actionable tips for maintaining team alignment in large Scrum organizations.

A radical change causes a cascade of decisions. If you notice that your strategy has to drastically change, like a completely new direction, you need to create a new strategy, set new numbers and goals to have a benchmark, decide on new KPIs, and all that has to cascade down to different organizational layers. 

It’s a great deal of work in every layer to lay out the tactics for the next time period. Good questions to ask in each layer are: 

• How should we change the KPI? 
• What can we do to reflect the new strategy and direction in our backlogs? 

Meaning the group backlog for the whole layer, but also every Scrum team’s individual backlog. There’s no place for features and ideas that don’t support the new common goal. Plus, it can provide a sense of relief to the team; cleaning out the backlog is a bit of a zen exercise.

Every now and then, there’s a magical moment when you check if your decisions were correct—as long as you have a feedback loop for the strategy, and a loop for each group of Scrum teams, and individual loops in each team. 

This is how you make sure that, from the bottom up, everybody is making progress towards their own KPIs, and the company’s main KPI.

Loops within loops within loops. That’s the beauty of Scrum, you can make a mistake as long as it’s checked soon, and if you’re gonna fail—do it quickly. This way you get a second chance to get it right, then a third chance, and so on.

I think a good solution is to talk with people about their roles, responsibilities, their areas of influence. They might not realize how many other people rely on their work. 

It also definitely helps to celebrate great decisions, and visualize the results of good work. At the same time, it’s not useful to hide mistakes, or when the work they did hasn’t resulted in anything meaningful. 

All of this can only happen in a culture of transparency.

Celebrating victories, understanding failures, it’s all crucial here. All this, coupled with the feedback loops we mentioned, and opportunities to fail quickly and try again, is premium oil for the engines of your Scrum teams.

It’s not as simple as patting people on the back or punishing them, this isn’t pre-school.

The key here is to translate KPI progress from percentages into something tangible. In ecommerce, even slight KPI progress can lead to thousands more products being sold every day. 

For example, instead of telling your team(s) “we grew a key metric by X%”, it would be better to say “thanks to your work, we sold Y more TV sets/wearables/pairs of shoes”.

You need to find a way to show how a specific change in the code, adjustment or new feature, leads to more satisfied customers that will come back. 

But that’s not all. There’s one thing that’s always going to happen in large teams, and that’s conflict. Let’s see how to handle it.

Having your teams divided into layers, and having a clearly-defined strategy are already good ways of avoiding conflict. Everybody knows what they’re supposed to be doing, so they shouldn’t invade into other areas. 

When there are discussions, transparency helps resolve them quickly. The ability to be open and change your mind when someone else is right is important, although like most soft skills, it’s hard to teach someone how to do this.

Leadership is a big part of solving conflicts. Companies are democracies to a point. At the end there has to be a person, or a group, to make the final call. 

It’s a matter of culture. Responsibility has to be clear, and it shouldn’t be hidden somewhere between groups or people.

This is especially important if you have to drop a project or a feature. Someone has to have the power to drop something when they notice that it goes against company goals. 

Which means that months of work could go into the bin, but things like this unfortunately need to happen sometimes.

When they do, transparency comes in handy again. Personally, in such cases I’d just say how I feel—it’s really sad, months of people’s work have to be discarded. The market has changed, that work doesn’t make sense anymore, it happens. 

It’s likely the team will feel just a little demotivated after that. So how do you get them excited again?

Show them what’s the next big thing, the next feature, the next project to focus on, and how this new thing will influence us as a company, and get us to our goals.

Being sad, being sorry and showing compassion are important, but outlining the next steps and getting people fired up about them is even more important.