Over the course of my career, I went from being a stakeholder in waterfall-managed projects, through introducing Scrum in a large organization, managing a single Scrum team as well as 20+ separate Scrum teams, all the way to my current position as Service Delivery Manager at STX Next. I’ve seen what it’s like to introduce Scrum in a traditionally managed environment, and what can go wrong in a single team, as well as a large group of teams. In this article, I’ll share the most important things I’ve learned, hopefully providing you with the tools you need to avoid critical issues in your Scrum team(s). If you prefer, instead of reading the article you can watch me discuss this topic in depth in one of our live sessions:
Problem #1: Goal misalignment between different Scrum teams
In a big organization with multiple Scrum teams, you’re always running the risk you’ll lose money, time and opportunities due to mismanagement.
It’s very easy to invest a lot of money in IT inefficiently.
The biggest issue I ever faced can be described as misalignment of goals, or lack of a common direction.
When you have 10, 20, 30 teams, even if they’re all working properly and using best Scrum practices, there’s a huge risk that some of them will choose directions that are not aligned with the main goal and strategy of the company.
Why is that? One of the main roles in a Scrum team is the Product Owner. That person decides which actions should be taken, which features to build, and ultimately—how their team will influence the rest of the company.
Left on their own, Product Owners from individual teams might make decisions focused too much on their own goals, and not on the goals of the company, which are usually related to growth, boosting the revenue stream and so on.
So the first thing we’ll talk about is how to avoid having multiple Scrum teams go in different, separate directions.
The worst thing that can happen is multiple Scrum teams going in different directions
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?
Diagnosing and solving the problem of Scrum team misalignment
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.
One solution for many problems: 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?
To be able to learn, you have to secure the possibility of making failures
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.
Maintaining team alignment
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.
Problem #2: Humanity at work—motivation and conflicts in large Scrum teams
The second big problem of large Scrum organizations is very basic and human. It’s the problem of losing meaning in your work.
You don’t want people to spend their time wondering “is there a real purpose for me being on this Scrum team?” or “is there any real purpose for my team?” An organized explanation of what your team does really helps here.
This problem boils down to motivation.
People want to be seen as, well, people. As human beings who, individually and as a team, are doing something that’s tangible, significant. If software were a house, they want to know which bricks they’re adding to it.
Personally, I need and want to be a part of something that’s useful, fruitful. And I’m not alone in this. Meaning is a basic need in life and work.
What can you do to ensure that people in your organization stay motivated?
Avoiding demotivation in a large organization
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.
Dealing with conflict
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.
Problem #3: Technological decisions in large Scrum teams
Having a lot of teams, they can make independent technological decisions. It’s good to have a framework that clearly defines limitations for these decisions.
You can choose the tech, but you have to be aware of what consequences it brings, and the variety of other technologies that can also be applied.
Missing this part can lead to chaos in your organisation, and make development needlessly expensive.
The solution here is easy to understand, but hard to apply. You need to work with the best people on the market.
Choosing technology is comparable to deciding how you will design engines in an automotive company. Sometimes the direction you take influences not months, but years of work, and you have to be prepared.
That’s why the architects and CTOs on your team need to be the brightest minds in the industry.
Now, should every little decision, every library be consulted with the CTO?
Not exactly. I found that a good solution is to create a guild of people who have the most experience, and let them challenge each other, discuss and decide what direction should be chosen.
Not every decision has to go through the guild, mainly those that have major long-term consequences across the organization.
It doesn’t have to be a guild, you can find your own mechanism of proposing different solutions, and having them challenged by the rest of the organization.
You don’t want people imposing their choices, it should be a discussion, maybe a competition of solutions, people playing devil’s advocate and looking for possible issues.
To make the right decisions, you need experts with vision and knowledge, but also a place, time, and opportunity to challenge that vision and discuss other options.
There’s a cool saying that goes back to Confucius, to paraphrase: “no friction, no shine”. As in, you can’t polish a gem without friction, same as you can’t make good decisions without a bit of friction in your team.
Final thoughts
To sum it up, the main problems that arise in large Scrum organizations are:
- Goal misalignment between different teams
- Demotivation and conflicts
- Tough technological choices
If you’re dealing with these issues, the first thing I suggest is to talk to your people, check if their minds and hearts are still there. Verify if the goals of your company are still valid, and if everybody understands them.
If you have 20 or more Scrum teams, I’m sure you’ve already checked all the frameworks for managing so many people. I’d use those frameworks as support, but still be sensitive to what makes your organization special, and use common sense when applying them. Keep in mind what’s valuable in your culture and try to boost it.
In the end, it’s about finding where the important things meet. The business goal, money, time, the human approach, people’s basic needs. When you merge them, you can find the right channel to grow these things in parallel, and then you’ll know that you’re headed in the right direction.
Building, or adding more internal Scrum teams can be a good way to get your product to the market faster, but it’s not the only way. If you want to build software quickly, or you need a group of seasoned professionals to analyze your Agile workflow, you can always hire STX Next.
To read more about different aspects of managing large IT organizations, check out these articles:
