If Scrum isn’t going that well, and you’re hitting problems and challenges in your organizational environment, the good news is you’re normal. It’s very common for teams to have significant challenges getting started with Scrum and other frameworks, because it involves a shift in mindset.
What we share here applies regardless of whether you are using Scrum directly or together with a framework such as SAFe. So the first step in working through these anti-patterns is to understand it’s totally normal these are happening. And the good news is that you’re here to make things better. You’re halfway there.
Here are the antipatterns you’ll want to avoid in order to get Scrum working properly.
Scrum Anti-Pattern #1: Believing Scrum Is a Universal Solution
The first anti-pattern is that thinking that Scrum is a universal solution. Scrum is a tool that’s used to solve a specific problem. Typically, the problem is posed as the question, “How do we organize ourselves to build things?” But here’s the thing: it’s not a universal answer to everything. Treating Scrum as a solution to everything will only lead to frustration.
The fix: Ask “Why?”
Since most people don’t actually understand why they’re doing scrum, the fix is to ask: “Why are we doing this?” When we stop and pause, we get answers.
We have a technology called the “Why Workshop.” It’s called the “Why Agile Workshop” in our other articles, but “Why Scrum” is the same thing. What it does is it gets people to step back and say, “Oh, we’re trying to make a better experience for the people who work here.” or “We’re trying to get products out faster”, or “We’re trying to increase the productivity of our group,” or whatever it is in your organization.
Whatever the reasons are, it’s really important to understand them. When people understand what the reason is, it gives them motivation and the desire to figure this crazy Scrum stuff out.
Scrum Anti-Pattern #2: Forgetting Scrum Is Part of Agile
The next anti-pattern is doing Scrum without understanding that it’s part of Agile. Agile is about a mindset or way of being. Scrum is a detailed set of roles, practices and steps – a very specific set of rules. Scrum is really helpful for people to begin understanding a new way of working, but it’s important to understand it’s part of a larger framework.
The Fix: Do Scrum AND Agile
Whenever you’re looking at Scrum, look at Agile as well. The real purpose behind Scrum is to create a shift in mindset, shifting people to working in a different way. Scrum is just a bunch of rules, and it’s a good start. But if you can get people learning, adapting, and working well together – which is the goal of Agile – you don’t really need Scrum.
Scrum Anti-Pattern #3: Focusing on Scrum Compliance
The next anti-pattern is thinking that following Scrum is the goal. Many organizations focus on getting Scrum compliance, making sure everyone is doing Scrum by the book, the way Scrum is designed to be.
Here’s the problem: the whole purpose of Scrum is to get people to think and to adapt to their environment, which means that the intention for Scrum is that you will evolve Scrum itself. Trying to get all your teams to do the exact same thing is a Scrum anti-pattern. We want all our teams to be doing different things, because they are different people working on different projects in different contexts.
The Fix: Evolve Process
The solution is to support Scrum evolution, or evolution of processes. Because our goal is not Scrum or Agile, our goal is to work more effectively.
Scrum Anti-Pattern #4: Scrum = Faster, Cheaper, Better
Some people believe that all they need to do is install Scrum and their organization will work faster, cheaper and better. This is of course, a problem with the culture and the mindset of the organization that Scrum will not fix.
Scrum is an empirical process framework that lets you know exactly how good you are, how average you are, or how badly you suck. It’s really just there as a tool to create visibility for what’s happening. It’s not a guaranteed formula to be faster, cheaper, and better.
The Fix: Understand Scrum is a Reflection
The solution to this problem is actually to work around the leadership team’s evolution, and their understanding of the laws of reality.
Since Scrum is just a framework to let you know what is going on so you can make the best choices possible, use it that way. Now, it turns out when you use it, you end up with much better outcomes. So, there’s a bit of truth in “faster, cheaper, better,” but it’s not primarily about that. It’s about exposing reality.
Scrum Anti-Pattern #5: Only Implementing Scrum in the IT Group
The next Scrum anti-pattern is thinking that Scrum is just for IT. The whole point of Scrum is to have a customer in the room. We want somebody who actually has the domain knowledge and knows exactly what needs to be built to be talking with the developers and the testers and the analysts.
The Fix: Involve the Business
The solution is to involve the business. And I mean really, really involve the business. The whole point is getting that live connection. It’s important to have frequent feedback and ask, “Hey, here’s what we did. How are we doing? How do we need to adjust and pivot? Are we getting this right?” Because the whole point of Scrum is to make sure we’re building working, tested software that meets our customers’ needs.
Scrum Anti-Pattern #6: The Scrum Leadership Gap
When starting out with Scrum it’s tempting to say, “Oh, we have a self-organized team. We have no hierarchy anymore.” But in Scrum we actually create two new leadership roles: the Scrum master and the Product Owner. Many in these positions don’t understand that their role is actually a leadership role, and nor do they have the tools to lead effectively.
Now, here’s the deal – your Scrum will only work as well as your leadership. Your Scrum master and Product Owner will limit how effective your Scrum team will be.
The Fix: Evolve Leaders
The solution is to focus on the evolution and training of the Product Owner and the Scrum Master so they fully understand their roles and how to function. This doesn’t just mean understanding the rules of Scrum, but also functioning in a more evolved way – a way that develops the people around them. We call this Evolutionary Leadership.
When you have a Scrum Master who is committed to their own evolution and finding better ways of working for themselves as well as their teams, then you’re on your way towards a high-performance team. Otherwise, the Product Owner and the Scrum Master will be the limiting factor for success of the team.
Scrum Anti-Pattern #7: The Scrum Mom
This pattern is called the Scrum mom. It’s the Scrum master that thinks that they are in charge of the team, and they act like a mom. They may be a loving mom coddling their teams or a bossy mom telling the kids to clean up, but both are still moms.
What usually happens is that the Scrum Mom is a Scrum Master, but they’re using command and control type behaviors. And what that does is it actually kills any attempts or moves towards self-organization, which is the whole purpose of Scrum.
The Fix: Support Scrum Master Growth
The solution for that is to understand that the Scrum master is really there to facilitate team performance. A Scrum master shouldn’t have any authority – they’re just there to support and enable the team.
The other part of the solution is to allow teams to fire the Scrum master. The teams actually make a decision about whether the Scrum master is working for them or not.
Scrum Anti-Pattern #8: Making Project Managers Scrum Masters
The next Scrum anti-pattern is making project managers Scrum masters. It usually goes something like this: “Hey, we’ve got all these project managers, what do we do with them? Let’s make them Scrum masters.”
Project managers are trained in command and control. They’re trained to drive performance and get things done. The job of Scrum masters on the other hand, is to look after people. It’s to support the evolution of the team as a cohesive system, so that it evolves to higher levels of capability and performance and achieves greatness. There’s a completely different set of qualifications needed.
The Fix: Give Scrum Masters the Training and Coaching They Need
In order to function as Scrum Masters, managers need to go through a fundamental shift. To facilitate this, you can set up a three month experiment: any project manager who wants to participate will be retrained and supported through coaching and mentoring. This covers not just the practices, but the mindset shift – how they show up as a leader.
Scrum Anti-Pattern #9: The Command and Control Product Owner
The next Scrum anti-pattern is the Product Owner that thinks that they’re in charge of the product. They get to decide what the product is and how the product will work. The problem is that their ego gets activated – they get attached to their vision that they can’t learn from those around them or see what is actually going to work.
The Fix: Don’t Dictate, Facilitate
The solution is to recognize that the Product Owner is a facilitation role. They’re responsible for identifying the most important work to complete for the next sprint or the next iteration, and for helping facilitate the conversation about where the product is going and what the customers need.
Scrum Anti-Pattern #10: No Working Products
The whole point of Scrum is to have a working, tested product that meets the customer’s needs at the end of every sprint or iteration. And then any feedback on their product is integrated for the next iteration or sprint. I’d say 95% of all Scrum going on does not meet that criteria, either because the work is not integrated with other teams, or because it’s not being demonstrated to a real customer, so there’s no real feedback on whether it’s actually working or not.
The Fix: Only Count Work That’s Truly Working
It’s important to demonstrate products to real customers if possible. If that’s not possible, it at least needs to be validated to make sure that the functionality is correct.
Scrum Anti-Pattern #11: The Daily Standup Sucks
A very common anti-pattern is that the daily stand-up sucks. The purpose of the stand-up is for the team to talk to each other about what’s the most important work to get done that day and how to do it. It’s not a status meeting reporting to the Product Owner or the Scrum Master.
Solution: Make Standups by the Team and for the Team.
Think of the standup like friends in the kitchen. You’ve got to make dinner, and you’re looking around at all the food supplies. “Who is going to cut this? Who’s going to cook that?” It’s a shift from stand-up as a status meeting to stand-up as co-creating a plan.
Scrum Anti-Pattern #12: Velocity Misuse
The next trap is velocity misuse. Velocity was intended to be used to create forecasts, and for the team to learn about how they’re functioning. When the velocity metric is used that way, it’s very, very helpful.
The challenge with velocity is that some leaders misinterpret it – they think velocity needs to go up, otherwise they’re not improving. In fact, the opposite can be true – a good team’s velocity number may actually go down as they improve, because estimating stories becomes easier and easier.
The Fix: Use Velocity for Forecasting and Understanding, Not Control
The healthy pattern is to use velocity in terms of the story points completed in an iteration. Use that information for the team to understand and evolve their own performance. It’s really an internal metric. It can also be used for the team to work with the product owner to create a forecast for when work will be completed.
Scrum Anti-Pattern #13: Boring Retrospectives
The next anti-pattern is running boring retrospectives where the same questions get asked over and over again. Where people don’t really feel safe talking about things, or the retrospectives aren’t talking about the real issues that are actually blocking the success of the team.
For example, they might be focusing on process issues instead of on interpersonal issues where the team members aren’t really collaborating well. What happens is when retrospectives are low value, people stop wanting to come, and they start canceling them.
The Fix: Discover How to Make Retrospectives Valuable
My advice is if people want to cancel retrospectives, to cancel them, because they’re there for the team to help improve. You can use that as a signal to learn what’s been going wrong with these retrospectives. Why are they so low value? What’s been happening? How could they be more valuable?
Take the time to listen. Get all the feedback, and then go away and look at what to do. And you can come back to them and say, “Hey, look, I listened to all your feedback. I think I’d like to try and experiment. Can we run a retrospective? I think I’ve got an idea of how it can address these things and actually create something really valuable for you.” And then of course you want to prepare an amazing retrospective.
In order to create an amazing retrospective, you can use the Retromat. What this technology does is it gives you different phases of the retrospective in different kinds of facilitation structures. You can pick the one that will work best for your team and keep it fresh. That way, you can start to regain your trust with the team, and create retrospectives that truly add value.
Scrum Anti-Pattern #14: Self-Organizing Teams
Self-organizing teams are a great concept. In order for them to work, you need people who show up and act like adults, and take full responsibility for their behavior. But if you don’t have people who are ready to take on that responsibility, it won’t work.
If people aren’t on an evolutionary journey to being adaptable and self responsible, throwing them on a self-organizing team can be a horrible experience for them. Because they’re being asked to show up in an evolved way without the support and guidance to understand how they need to do so.
The Fix: Give People the Right Amount of Authority
The solution is to evolve your people first, and only give your people the level of responsibility that feels right for them. Many teams will benefit from more guidance from their managers or other people in the system to give them the safety and support.
It’s easy to say people are self organizing, but if they’ve been conditioned by an oppressive work environment, they won’t know what to do with that freedom. The solution is to evolve the people, and support them and give them the right level of authority and power.
Scrum Anti-Pattern #15: Telling Teams They’re Autonomous
Telling teams they’re autonomous is just setting them up for failure. The intentions are good – we’d like to have highly autonomous teams. But at the start, most people aren’t showing up in a responsible enough way for that autonomy to make sense. And if all of the teams just look out for their best interests, they won’t always do what’s best for the organization as a whole.
The Fix: Develop Sense of Interdependence
The solution is to create a shared sense of interdependence. Have teams focus on the shared goals of their group, not optimize locally. If teams know their priority is optimizing for the shared goals of the organization, then everyone will benefit.
Final Thoughts
Once you’ve gone through this list of anti-patterns, you may be saying, “Oh my goodness, we’re getting everything wrong.” And our answer to that is, “It’s okay.” It’s very normal for most organizations to run into many or almost all of these anti-patterns.
The reason for this is Scrum is a representative Agile, which itself is a change in the culture of your organizational system. So many organizations inadvertently attempt to change the culture to shift to a more progressive way of working and being through Agile, through the Scrum process. And that’s why it’s normal to run into many or all of these challenges.
The solution we found to this is to evolve the people in the organizational system so that they can benefit from Scrum, Agile, and other new ways of working. We’ve created the SHIFT314, Evolutionary Leadership Framework™ to provide a guided way for people and organizations to evolve, to create a context where Scrum, Agile, and other new ways of working can unlock and fully thrive.
Many organizations go about things backward. They introduce Scrum and discover all these problems with the people and the organizational system. With the SELF model, we start with the people, and we evolve them first so that when changes are introduced, it’s done in a way where people get the maximum benefit. Where the changes are introduced just at the right time, at the right scope and the right change that people can integrate and get value from, rather than overwhelming them with a tidal wave of change.
