Learning at Work Week: Signs of a Failing Scrum Team (And Some Ideas To Help)

18 May 2018 | Chris Wintle | About a 8 minute read
Tags: Agile, laww, Learning, Learning at Work Week, Scrum, team

At AND Digital, a huge part of what we do is to help businesses with their transformations to becoming true Agile organisations, but it’s not always straightforward or easy for any business to adopt Agile at scale.


Scrum is not a silver bullet. It’s not a system designed to make development teams run faster or more efficiently out of the box – it’s a lightweight framework designed to help manage complexity and allow teams to have enough empowerment to make decisions and act on them (and to gather data to make sure this is all happening).


This misunderstanding often leads to high failure rates when we try to implement Scrum. If we don’t understand what it is we’re actually trying to do in the first place – we’re not very likely to succeed.


With that in mind, it’s worth looking at some of the common symptoms of a dysfunctional Scrum team and thinking about a) What those symptoms mean and b) how we can help to solve the root cause.


The Problem: Boring, Low-Energy Daily Scrums

One of the more common symptoms of a team that is unlikely to succeed is that the Daily Scrum is a routine, low-energy event where each member of the development team answers the ‘three questions’ (what I did yesterday, what i’m doing today, any blockers…) in turn, typically in monotone.

When this starts to happen, it is usually indicative of a team that does not see the value of a Daily Scrum. This is usually because the Daily Scrum has started to become a daily ‘status update’.


Firstly, having a daily status update is boring, and not overly helpful within the context of an Agile organisation. Secondly, this is missing the entire point of a Daily Scrum – which is to plan how the development team are going to build things over the next 24 hours. This is very different to just talking about what you’re going to work on today, it’s about planning for what problems might come up and to talk over how you might solve them (and call out what help you may need)


This problem could be a symptom of a more serious problem, which is that the business hasn’t bought into Scrum. In that case there’s no simple fix. There are however some small fixes we can try on a smaller scale:


Solution 1: Get the Product Owner out of the Daily Scrum

As per the Scrum Guide, the only people that actually need to be at a Daily Scrum are the development team. It’s sometimes useful for a PO to attend, but if they’re attending regularly, there can be a natural tendency for the development team to start talking ‘at’ the PO – to update them on what they’ve been doing. As soon as that happens, it’s a status update meeting.

That’s not to say the PO should never attend, but try just attending now and again, rather than every day.


Solution 2: Shake up the three questions

The ‘three questions’ are suggested by the Scrum Guides to act as a guideline to make sure the important information is being talked about. They’re not there to be used verbatim forever.

Try changing the questions up slightly. Try adding another question, such as Who wants to pair with me for an hour today?”,“Who is working on something new so I can learn something?”, “What do I hope to learn today?


Solution 3: Get a ball (seriously)

You might see development team members going around in a circle talking in order, which is a seriously boring way of spending 15 minutes.

One thing to try here is to get a ball (it doesn’t matter what kind). Only the person holding the ball can speak. Once they’re done, they then throw the ball to a random team member who hasn’t yet spoken.


This may sound trivial (and perhaps dumb), but it serves to make sure everyone is alert and engaged (in case they have to catch the ball) and just makes the process a little more fun.


At AND we tend to use this technique for the majority of our Daily Scrums with our clients!


The Problem: Pointless Sprint Reviews

I’ve been to more pointless Sprint Reviews than I can count. A PO or Scrum Master makes a slide deck which shows the sprint burndown and a rough overview of what was built. They run through the deck for an audience that isn’t overly bothered. Then everyone files out of the room. Nobody really learned anything other than ‘some stuff was built’, and anything between 9 and 15 man-hours were used up.


This kind of Sprint review is symptomatic of a few problems. The most concerning of which are a) A business which isn’t excited or engaged about what it’s building and b) A Scrum team which isn’t proud of its achievements.


Solution 1: Get a bigger room. Invite everyone

A good question to ask is ‘who is a stakeholder’ for your team? If you really think about everyone that has a stake (or interest) in your Product, you’ll probably come up with a lot more people than the handful of ‘official’ stakeholders that come to your Sprint Reviews. Invite everyone who has even the most vague interest in what you’ve built. The Product you’re building affects far more than a handful of people, so get as many people as possible to come see what you’ve built. You’ll get more feedback and your business will have better visibility of what’s actually happening over there in the delivery teams.


Naturally if you invite lots of people, you’ll be using up a lot of peoples’ valuable time, so it’s important that the Review get tailored to be useful to the audience that has accepted!


Solution 2: Shout louder about what you’ve achieved

Building a product is really, really hard. At the end of every sprint everyone in the team has solved problems, overcome obstacles and pushed through challenges. Despite this, all we usually have to show for this in a Sprint Review is ‘We achieved 70 story points and met one of our two Sprint Goals’.


A Sprint review is a great forum for advertising the great work that the team have done. Single out accomplishments. Talk through interesting challenges. Shout from the rooftops about all the cool stuff you’ve built.


Failures matter too. Development often seems like a black box to the wider business – by talking about stuff we failed at, we can give the business a better understanding of what actually goes on in the day to day of a Scrum Team.


Solution 3: Shake up the format

If your Sprint Reviews consist of running through the same slide deck format every two weeks, is it any small wonder that the team and the business aren’t massively engaged or interested?


Try getting different team members to come up with different formats for each Review. Get different team members to present it . Often, we have reviews where the PO is the only person to talk during reviews. It makes sense for the team members who built a feature to be the ones to talk about it!


The Problem: Ineffective Retrospectives

There is little more demoralising to a Scrum team than a going-through-the-motions Scrum Retrospective where very little gets agreed, very little changes, and so on.


This one is a little harder to pinpoint to any particular ‘quick fix’, as there are so many reasons why this might be happening. The most common is the team not being empowered enough, but that’s too big a problem to tackle here. There are some small fixes we can try from within the Retro itself, though:

Solution 1: Always have actions. Review whether they got done

Retrospectives can often end up being a slight hand-waving exercise where everyone talks about good stuff and bad stuff without actually assigning any actions for how to address things. And even if these actions are created, there’s no real accountability for acting on them.


Every Retro should have an output of actions and people assigned to them. Scrum is all about empowerment and accountability!

Ideally we should start each Retro by talking over what happened with the actions from the last one. If we do these two things, we can at least start to track whether we are gaining meaningful and measurable change from our Retros!

Solution 2: Change the format now and again

The format of “good stuff, bad stuff, actions” is a good one, but sometimes it’s worth shifting the format even if it’s just to experiment a little and see if we can improve things. have provided a great list of alternate Retrospective formats here:

Final words

Naturally this isn’t an exhaustive list and your mileage may vary depending on the exact problems you’re facing within your own business. Scrum is centred around the idea that we should always be improving how we work, so experiment with things that work for you – and remember to measure the results! You’re not going to get everything right in one go – Scrum is a a process of iterative and incremental improvement as well as delivery!

At AND we’re constantly trying to help our clients improve – but we can’t do that unless we’re constantly improving and experimenting ourselves, so watch this space for more thoughts on what works for us and what doesn’t!


Read More From This Author

Share this blog post

Related Articles


We’re looking for bright, dynamic people to join our team!

Discover More Roles