Strange things people do and still say they do Scrum

Scrum recently celebrated its 21st birthday. There are now over 400,000 Certified Scrum Masters, and that’s even before counting the ones holding the competing Professional Scrum Master certification!

Sadly, with so many people using Scrum, there is also a lot of madness going on in the name of Scrum. The State of Scrum report from the Scrum Alliance contains some rather sobering reading. For example, only 15% of Scrum teams are self-organising. Even worse, only 6% are cross-functional. Can it be that there are a lot of people claiming to “do Scrum” who are completely missing the point?

Looking at a team from a distance, it may all seem nice and dandy. They may be working in 2 week sprints with a planning meeting at the start and a demo and retrospective at the end. Every morning, they stand up in front of a wall full of index cards and sticky notes, telling each other “Yesterday, I…”. However, when you look closer, you may realise it’s all a façade.

If we just see the activities, roles and artefacts of Scrum as a checklist we need to tick, without buying into the values of the Agile Manifesto, we’re not really doing Scrum and we certainly won’t be agile.

Let’s have a look at what some of the pitfalls are!

1. Not having working software at the end of the sprint

The purpose of a sprint in Scrum is to have produced working software by the end of the sprint. Delivering working software frequently is what makes agile different from delivering software in the “waterfall” way.

There are several reasons why this is so important:

  • Short feedback loops. It is very hard for users and customers to give us useful feedback until we’ve built enough for them to see the functionality in action. If we spend four sprints before we learn that our underlying assumptions were wrong, we will have wasted a lot of effort!
  • Limiting work in progress so that we can be flexible when conditions change. If 60% of the most valuable features are done and working, we’ve got something that provides significant value to our users. If we’ve instead have got everything 60% complete but nothing done, stopping now would mean throwing all our efforts away!
  • Knowing where we are. Without working software, we’re queueing up surprises. If there is a risk we’re building the wrong thing, how can we possibly know how much work is remaining? And if testing happens later, what’s to say that we won’t need a couple of sprints extra just to deal with the bugs?

2. Teams that are not cross-functional

Only 6% of Scrum teams being cross-functional means that 19 out of 20 teams don’t have all the knowledge and skills they needed to complete their working software in the sprint without depending on others outside of the team.

For example, this might be the case where a team is missing people with skills in user experience design, databases, software architecture or testing.

This quickly reduces the benefits we’re likely to get from Scrum:

  • Flexibility — If we see that some change would be beneficial, we would have to go back to a database team or a design agency to ask for changes. The time and/or cost of these changes might mean we park them in the backlog instead and never return to them.
  • Creativity — If someone else designs the solution, technically, UX-wise or both, and we just paint by numbers, we will get very little room to come up with the best solution. We will have very little scope to work together with the users to make sure that we build what will have the biggest possible impact.
  • Productivity — Dependencies on others may block us. This could quite easily prevent us from delivering our work in the sprint. To avoid that, we might be tempted to introduce a Definition of Ready, defining that all dependencies must have been delivered before we start our work. First, team A do their bit and then team B do theirs. But hang on… Sounds a bit like “waterfall”, doesn’t it?

We are unlikely to be able to remove all dependencies. However, to be agile we need to at least remove the ones we create by drawing the wrong lines in our org chart.

3. Building towards a fixed specification with no interest of acting on feedback

At the heart of Scrum is the idea to inspect and adapt through incremental and iterative development. We build something, get feedback and decide based on that how to proceed. We use Scrum to discover what to build.

If we believe we know exactly what we need and we have no interest in acting on what we learn and the feedback we get along the way, Scrum is pointless. Maybe it won’t hurt us but certainly don’t count on getting much benefit out of it.

4. Micromanagement

In agile, we rely on self-organising teams to come up with the best and most effective solutions. When we’re members of an agile team, we self-organise to reach a shared goal. We don’t rely on anyone else to tell us how to build the solution or to decide who works on which task. When some requirement or information is unclear, we find the clarification we need. When something doesn’t make sense, we question it. If something proves harder than we thought and one of us gets stuck, we reorganise ourselves to help them out.

For self-organisation to stand the slightest chance of working, the team must be given the trust and authority to self-manage. One guaranteed way to prevent a team from self-organising is for someone to step in and make decisions for them. Even if it’s just when things get a little bit sticky.

5. Big teams

Scrum prescribes small teams with between 4 and 9 members. The reason for this is simple: coordination and overhead grows when the team grows.

Yet, 10% of Scrum teams are bigger than the maximum 9. That’s when the Scrum activities really start to struggle.

As an illustration, let’s assume that we have got 15 people in the team and that three people can usefully work on each backlog item together. That means that any one individual is only likely to work on one out of every five items we discuss in the sprint planning meeting.

Likewise, in the Daily Scrum, we’d have less than a minute each to discuss what we’re working on. Most of the other’s updates will be about things we’re not involved in. There will just be too much work going on to be able to care about everything!

When we stop caring about what the others do, there is a big risk we will move from being a team, self-organising around a shared goal, to “Well, I did my part”.

6. Not continually improving

Whichever agile approach we take, one of the most important things we can do is to always look out for problems that are holding us back. We come up with ideas for how to fix them, try those ideas and see if things improve. And if they don’t, we try something else.

Rather than big, disruptive changes, we take one small step at a time. Each sprint, we will be a little bit better than the last one. Over time, these improvements will add up to a big change in effectiveness.

The mechanism for this in Scrum is the Sprint Retrospective. Yet, according to the State of Scrum Survey, 1 out of 5 Scrum teams don’t have a sprint retrospectives.

Some teams might well have some other way to make sure continuous improvement happens but many won’t. Maybe they are “too busy doing real work” to have time to remove the problems causing them to be behind in the first place. Others may have felt they kept raising the same issues retrospective after retrospective but nothing ever changed, so they stopped doing them.

Whatever the reason, the cost of not continually improving is high. Feeling that we’re wasting a lot of time and effort dealing with avoidable problems can be a huge drain on motivation.

7. Enforcing certain tools and “best practices”

People often see Scrum as a set of tools. For example, some might say that “In Scrum, we estimate our user stories in story points using a Fibonacci scale”. However, nothing mentioned in that statement is actually part of Scrum!

Scrum is clear that we must use empirical methods for our forecasting and decision making, i.e. base them on actual progress and events. However, it doesn’t recommend any particular method over another.

For example, the #noestimates approach of breaking every backlog item down into very small potentially shippable pieces, and measuring our velocity as how many of those we get through, is perfectly fine.

This freedom to do what we see fit is how continuous improvement becomes possible. Teams can experiment and find what works for them. If we think there is such a thing as “best practice”, how could anyone ever get any better?

8. Making every team do things the same way

With teams everywhere coming up with new ideas, there is a good likelihood some team will start doing things that other teams would benefit from doing too. When a manager sees this, they may, with the best of everyone at heart, declare that “From now on, every team must do x!”.

Unfortunately, these kinds of directives risks reducing the continuous improvement. What’s to say that some other team didn’t already have a better solution or were just about to come up with one?

The way to spread ideas in an agile organisation is not to through management but through people. For example, some places use internal communities, where members from different teams get together to talk about a topic they feel strongly about. It doesn’t even have to be that formal. Maybe it’s just someone picking up an idea from someone in another team she spoke to in the coffee queue the other day, and suggesting it in the next retrospective.

9. Seeing goals as commitments

The word “commitment” was dropped from the Scrum Guide a long time ago. The team makes a forecast what they will complete in the sprint. Nevertheless, the mind-set of the sprint goal as a commitment seems to live on in far too many places.

“Software development is not a sprint, it’s a marathon” is the hard to argue with slogan of many people fed up with Scrum as they’ve seen it practiced. To be successful, we need to be able to keep evolving our product over a long time. If we see our sprint goal as a commitment to reach at any cost, we will not only get exhausted. We will also end up with a code base that gets increasingly hard to work on due to the shortcuts we’ve felt we had to take.

A good sprint goal needs to be ambitious in the right kind of way. We need to know what we’re trying to achieve and why. If our sprint goal is “Jira tickets XYZ-123, XYZ-124, XYZ-125, XYZ-126”, we’ll have no flexibility and will have failed if we miss one of those tickets.

A more flexible goal statement, such as “a basic version of the shopping basket” not only gives us a better focus. It also allows us to have useful discussions around the scope (e.g. “Do we really need to be able to adjust the quantities in the basket right now?”) if the sprint is starting to run out.

10. Not measuring throughput

As agilists, we base our forecasts and decisions on data, rather than just guessing. In order to predict how much work we can do in the future, we measure how much work we’ve done in the past.

Just as importantly, though, by keeping track of how quickly we are getting through our work, we are also able to see if the changes we make as part of our continuous improvement are increasing that throughput.

Again, Scrum doesn’t specify how we should do this. We can, for example, choose to measure velocity in story points, if that is how we estimate our work. Or we can count the number of backlog items done if they are all roughly the same size.

The important thing is that we have a measure that allows us to both forecast what’s ahead of us, so we can make decisions, and evaluate the changes we make.

11. Misusing the transparency

Scrum provides openness and transparency, making it visible how we are progressing. We don’t hide uncomfortable facts when something doesn’t go as we were hoping. Instead, we adapt to the situation.

However, this requires a high level of trust. If someone with an old-style mind-set of command and control starts misusing the information and we feel exposed, we are likely to start protecting ourselves by hiding information.

For instance, let’s say we’re seeing after a couple of sprints that things aren’t going quite as quickly as we would have hoped. A good response would be for the team to look at what’s holding them back. Maybe there are some blocked dependencies? Maybe the build server is causing us trouble? Or might everything be going well and we were just overly optimistic? Maybe it’s the expectation that needs to be adjusted and some low priority requirements will need to be dropped?

A less useful response would be for a manager to demand that people put extra hours in until we’re back on track. Another would be to simply add more people and assume velocity would increase.

Likewise, if our bonus is influenced by how many story points we complete as individuals, two things will happen. Firstly, our estimates will go up (the easiest way to do more points!). Secondly, we will focus more on “getting points” ourselves than whether the team and product reach the actual goal, which is to deliver value.

12. Using Scrum when something else would work better

Finally, let’s not forget that us having paid money for people to become Certified Scrum Masters is not a valid reason to do Scrum. We should do Scrum because it is useful for what we are trying to do. If something else works better, let’s do that instead!

For example, if our team’s work mainly consists of responding to urgent requests, using fixed sprints and trying to plan two weeks ahead just doesn’t make any sense!


We must always remember that the activities, roles and artefacts in Scrum are not there despite the principles in the Agile Manifesto. They are there because of those principles.

If Scrum as we have implemented it in our team feels at odds with the Agile Manifesto, it might well be. Let’s take a step back and see what we need to change in our implementation.

What we must not do, however, is to ignore the core parts of Scrum. If we do that, the result will not be Scrum and we will not be agile.

Thanks for reading this post! If you found it useful, it would mean a lot to me if you spread the word by hitting the heart button. 💚

I first published this post on my personal blog Magnus Dahlgren — Thoughts from a Scrum Master on the 2 February 2017.