9 quick fixes that won’t solve your Scrum problems

Categories Agile
Quick fixes

Improving how we do things is at the heart of any agile methodology. We’re always on the look-out for opportunities to improve. Through this continuous improvement, we’re on a constant journey towards finding the ways to delivering as much value we can, as effectively as possible.

However, if we’re not looking deeply enough to find the root cause of the problems we’re seeing, the risk is that we end up attempting quick fixes. We try to address the symptoms rather than the cause of our problems, or we sacrifice long-term sustainability for short-term benefit.

In this blog post, I will look at some such quick fixes which may seem like a good idea at the time but that are likely to come back and bite us.

Let’s get started!

1. Adding more people to the team

In traditional project management, the “iron triangle” tells us that if we want to finish sooner and scope and time is fixed, we need to increase the resource. However, reality rarely works that way.

Longer term, if the team is too small, more people can definitely help but it will never be a quick fix. When things are going slower than we prefer, it will never be the matter of adding 20% more people to get 20% more output.

New team members will need time and help from their team mates to get up to speed and any changes to the team will unavoidably cause some disruption, reducing our velocity in the short term.

Also, the bigger the team, the bigger coordination effort. The State of Scrum survey backs this up: if a team is bigger than the 9-person maximum, their success ratio will actually fall significantly.

2. Using the daily Scrum to micro-manage the team

The daily scrum is a place for the team to organise their work for the day. When a scrum master or product owner are not clear on their own responsibilities and the purpose of the daily scrum, they may be tempted to step in to try to manage the work of the team. “Bob, why don’t you do those two tasks together, since they are in the same area and Rachel, you can pick up that bug I raised yesterday instead”.

Agile methodologies require a great deal of trust. We can’t on one hand say the team is self-managing and on the other step in and micro-manage them as soon as something is done differently than we would have done.

Will the actions of the team cause irreparable damage and put the future of the company at risk? If so, it would definitely be irresponsible not to let them know. Fortunately, those kinds of issues are very rare. Much more often, it’s just the question of two different ways to do something.

The manager needs to stand back and consider: What will have the bigger long-term effect? Me stepping in now and telling the team to do such-and-such, or the team identifying in their next retrospective that they could do something in a better way?

3. Making the team “commit” to the items in the sprint

The first version of the Scrum Guide, which is the document that describes “the rules of Scrum”, talked about the team committing to the items that make up the sprint goal. Despite this changing many years ago, to the team making a forecast, some still hang on to the old way. It’s easy to see why. It’s quite convenient agreeing with the team at the start of the sprint what they will do and them then just going away and do it. No ifs, no buts.

In real life, it is impossible to predict what will happen during the sprint. Things may be more complicated than we thought. We may realise it makes sense to implement something slightly differently. The old code may be in a worse state than we thought. People might get the flu. The live site might break.

Having no flexibility during the sprint will lead to undesired effects. We will end up taking shortcuts if we feel we have to, building up debt that will slow us down in the future. Or we’ll settle for a goal so insignificant there is no risk we will miss it. Neither of these contributes to delivering the most value we can in a sustainable way.

4. Getting rid of the sprint goal altogether

The previous point is not to say that the sprint goal isn’t still incredibly important. Having an objective for our sprint gives us a focus to work towards. If we’ve said that we’re aiming to have a very first version of the shopping basket available for user testing, now is probably not the right time to rewrite the stats tracking script for the search result page.

5. Skipping the sprint planning, review, retrospective or daily Scrum

The Scrum framework prescribes several meetings. At the start of the sprint, we have a sprint planning meeting. Each day during the sprint, we hold a daily Scrum. At the end, we hold a sprint review, followed by a retrospective.

Together, these add up to a significant amount of time, possibly a day or more for a two-week sprint. If one of these meetings doesn’t give us the value it’s supposed to, it is clearly very tempting to just get rid of it.

However, let’s never forget that all these activities are there for a good reason. If we get rid of one, we’re likely to be addressing symptoms rather than solving the problem. For example, if the sprint planning makes us lose our will to live, chances are that the backlog grooming beforehand isn’t good enough, or maybe we’re looking at the wrong level of detail. If the retrospective raises the same points sprint after sprint, the issues clearly aren’t getting addressed. Let’s fix that instead!

And remember: a time box states the maximum for how long we allow a meeting to go on. We can finish much sooner if we’ve achieved the goal quicker!

6. Using velocity to measure teams

Scrum puts the emphasis on empirical methods for forecasting. One such method is estimating backlog items in story points and then count how many points we complete each sprint on average, i.e. the velocity. The assumption is that, all things being equal, we are likely to achieve a similar number of points in the future and we can forecast how many sprints we need.

However, if we start using this velocity in ways it’s not intended, such as management setting a goal to increase velocity by 20%, bad things will happen.

The problem is that story points don’t actually mean anything. They are just a relative measure. If our goal is to deliver more of them, that’s very easy to do. We either just make the estimates bigger or we cut some corners. Neither of those help us reaching our real goals!

7. Mini-waterfall

One of the most common challenges in Scrum is probably how to deliver something valuable and potentially shippable each sprint.

We will have a big goal in mind and a number of features to deliver as part of that. How can we possibly slice those features into small user stories that we can complete several of in just a couple of weeks?

It is very easy to fall into the trap of waterfall thinking, where we deliver one part of the architecture after the other, rather than a little bit of everything every sprint. Instead of user stories, we end up splitting our work into technical tasks. Let’s create the database model this sprint, the API next, hook it up to the front end the one after and style it in the fourth sprint.

The problem, though, is that if we split our work that way, it will take a long time before we can get any feedback from the customer and, ultimately, the users. It will be very rare for a user to be able to look at a JSON API and say: “Yeah, that’s what we need!”. In the above example, we will have spent four sprints before we can get feedback. By then, when we’ve built the whole feature, it will be much harder and more expensive to take their feedback into account.

And what if we were to stop after the third sprint? We would have shipped nothing of value to the user!

8. Making all teams work the same way

When well-meaning managers observe that teams work in different ways, they may be tempted to try to make things more similar. They’ve no doubt got the best intentions: to spread what works and eliminating what doesn’t.

However, different teams have different needs. It would also be naïve to think that there is no better way to do something than what we’re doing currently. That’s why we use continuous improvement. This thing we did worked well so let’s do more of that. And might it be even better if we try this new idea? Let’s try and see!

Trying to apply quick fixes from above, like mandating how the teams work is the most effective way possible to prevent this continuous improvement from happening.

This is not to say that we should not learn from other teams. Communities, for example, can be incredibly useful for this.

9. “Following Scrum”, no matter what

Scrum has got a well-defined set of rules. In the Scrum Guide, the inventors Ken Schwaber and Jeff Sutherland are very clear:

“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”

In reality, these rules actually allow a great deal of flexibility and prescribe very little detail. Only the basic roles, events and artefacts are included. Some people are very surprised when they realise that burn-downs or standing up during the daily Scrum are not part of the rules!

Nevertheless, the mere existence of these rules seems to have created a perception of Scrum being very strict. Some are put off the framework for this reason, while others jump straight in, pointing fingers and telling others “You are doing it wrong!”.

Regardless of which camp we’re in (or if we’re somewhere in the middle), our first step should be to make sure we understand what is part of Scrum and what is not. Thereafter, we should make sure we understand the purpose of each part of the framework. Once we’ve done that, and we identify a better way to achieve that purpose, who can stop us?

And finally, let’s not forget that other frameworks are available. Maybe Scrum is a good fit for what we are doing, maybe it’s not. Just as with anything else, let’s inspect and adapt!


Common for all the quick fixes we have looked at above is that they tend to address a symptom, such as “We’re too slow!” or “This meeting sucks!”. Doing so will never solve our actual problems. Instead, we need to dig deeper to identify root causes.

That is a subject I will return to in future blog posts.

Have you ever caught yourself trying to fix the symptoms? What happened? Share your experiences in the comments below!  

Magnus Dahlgren – Scrum Master (CSP) and aspiring Agile Coach

Leave a Reply

Your email address will not be published. Required fields are marked *