Troubleshooting Scrum

Six phrases of agile doom

The words we choose, often communicate more than the words themselves

With this in mind, here’s six phrases that are often red flags when used in agile projects. Their use is more often than not a sign of underlying issues that will impede a team’s ability to truly perform.

1. “We’re doing what works for the team”

A noble expression which on the surface might seem to be exactly what agile is all about; responding to change and adapting to the circumstances.

But, does it work for the customer, or for the business, or for the stakeholders? What ‘works for the team’ might be building up large amounts of un-shippable work, or working on features that simply aren’t the stakeholders’ priorities.

Could something else work even better, but require a bit of effort? Doing ‘what works for the team’ is often synonymous with resisting change, or a lack of understanding of the landscape. It reminds me of being a child and trying to fix a relative’s computer when something is obviously wrong with it, but they resist change because they are comfortable with what they currently have, flawed as it may be.

Agile practices and techniques typically shine a very bright spotlight on problems. For example, Scrum won’t fix problems with weak product ownership, but it will make it very obvious. Many teams choose to switch the spotlight off rather than fixing the issue. If hiding from problems is what ‘works for the team’ then there are definitely significant problems underlying.

2. “We do [/don’t] do this because we’re agile”

“Agile” doesn’t tell teams what to do, so quite simply should never be used as justification for doing something. Yet, it often is.

“We’re agile, so we don’t write documentation”, or “agile says we should estimate user stories” and many other variations echo through the hallways of many companies, both large and small.

“Agile”, or more accurately the agile manifesto does outline some values and principles, and of course teams should use these to help guide them but they are not in themselves justification or reason.

3. “Sprint Demo”

What if the Sprint Review was an opportunity to do more than just inspect the increment? What if teams could also use this to look at the Product Backlog, and work with stakeholders to better understand what to do next? What if they could look at the market and see how it has changed, and make decisions based on that? What if the Development Team provided some insight into their work, which could then be understood by stakeholders and improvements to their interactions made as a consequence?

Good news, the Sprint Review is all of those things. Teams mustn’t miss this opportunity if they want to be successful.

4. “That’s an idealism”

While some companies release software to production many times a day (some do it many hundred or even thousands of times a day), others continue to insist that it simply isn’t possible for them to release more than once a quarter.

At its core, agile is all about ‘working software over comprehensive documentation’, and so it is little wonder that almost every agile practice that you come across is rooted in the real world, in real teams, doing real work, for real customers. They’re not born out of University research departments. So when people insist that it simply isn’t possible to deliver working software at least every Sprint, or that stakeholders will never be engaged with the team on a regular basis, their competitors continue to surge ahead.

5. “Our goal is to do the Sprint backlog”

If this is your thinking, just do continuous flow because you’re missing one of the most fundamental parts of Scrum. Sprint Goals represent the valuable increment that teams are working towards, and when the increment has value no greater than the sum of its component parts, Scrum is likely not an effective way to manage a complex project.

6. “Scrum says…”

Similar but still different to #2, this is a great indicator of a lack of knowledge and understanding of Scrum within a team.

There are times, of course, when a team or team-member needs to have the rules laid out in front of them, particularly if they are just beginning their agile journey (‘shu’ stage where simply following the rules is the best option), but generally speaking once a team starts to mature, teams are coached and guided through underlying principles, concepts and values. They should be committed to their decisions and to their process, which they are unlikely to be with purely a rulebook to guide them.

So, when teams choose to skip their Sprint Review, a good Scrum Master won’t simply open the Scrum Guide and recite that “a Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. Rather, they will explain why this event is valuable, and the potential consequences on the team’s ability to inspect & adapt, and on transparency, if it were to be skipped. They will also recognise that when a team is thinking about skipping something like the Sprint Review, it is probably a sign that the event isn’t working, and the root cause isn’t the event itself but rather something deeper: maybe it’s just being poorly run, or maybe — in the case of the Sprint Review — there are no stakeholders engaged with the project, or maybe the team simply cannot deliver a ‘done’ increment within the Sprint time box so there is nothing to review.


These phrases are not guarantees of problems, but they are often very good warning signs and allow for a very quick assessment of team health.

Ineffective or long Sprint Planning sessions

I’ve spoken to a number of people recently who have been struggling in their Scrum teams, specifically with planning sessions feeling ineffective and taking up too much of the team’s time.

When planning sessions take too long, there are a few common causes that I have come across, but at the top of the list is that the Sprint Review isn’t covering everything that it should. I’d estimate that around 80-90% of the Scrum teams I come into contact with call the Sprint Review a “demo” which is usually reflective of what their Reviews consist of and where the focus of this session lies.

My own team was struggling with this element until fairly recently, so I have experienced first hand the impact that ineffective Sprint Reviews can have on Sprint Planning.

The Sprint Review is explained fully on page 11 of the Scrum Guide if you wish to re-familiarise yourself fully, but it is specifically this action that I find is typically forgotten:

“The entire group collaborates on what to do next.”

“The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”

If the Scrum Team and stakeholders aren’t reviewing and revising the product backlog as part of the Sprint Review there is a high probability that the team are entering Sprint Planning without a clear understanding of the Product Backlog Items that are likely to be included in the Sprint. This means that they are coming across the items for the first time when they should be firming up their understanding enough that they can assert with relative confidence the effort and time required to complete the item. Instead, they are wrapping their head around the high level concept before hurriedly making a sizing decision.

Of course, the team should be aware of the backlog prior to the Sprint Review, but teams that aren’t perform the appropriate actions are in all likelihood also not performing adequate Backlog Refinement.

This may mean that you need to make your Sprint Review slightly longer, but the additional focus in this area may well be all that the team requires. Chances are though, that the improvements your planning sessions (and consequently the entire Sprint) will be worth a little bit more time in the Review — remember, transparency and understanding are fundamental parts to your team’s success so don’t be afraid to invest time improving them!