I have been on some really successful and well-oiled Scrum Team machines, but I’ve also shared in the misery that is broken Scrum (aka Zombie Scrum, Fake Scrum, or whatever other term you give to dysfunctional groups of people who work “together,” but aren’t really operating as a team). As such, I’m writing two blogs on how to detect that something might be wrong with your Scrum Team. Here are 10 symptoms to watch out for in Part 1:
- Not creating Sprint Goals
Nothing spells a dysfunctional Scrum Team like the lack of Sprint Goals. This is one of the most persistent mistakes I have seen most teams make. Not having Sprint Goals means there’s nothing to aim toward during an iteration – no North Star. What usually ends up happening is that the team ends up picking a disorganized hodge-podge of different things. This results in a Frankenstein-style set of stuff to share at a Sprint Review, and it ain’t pretty.
- Biting off more than you can chew
Another extremely common behavior I have seen by bad Scrum Teams is that they always bite off more than they can chew. This could be the result of intense pressure by the business, or just an inflated sense of what the team can do. Rather than constantly overloading each Sprint, the team would be better off taking a pause and getting realistic about their capacity to deliver. Then, they could pick a smaller set of stories and focus on getting them all the way across the finish line. It feels good to deliver and be successful!
- Ridiculously Unrealistic Estimates
One root cause of the last problem might be that teams also suck at estimating. And when I say this, I mean it both for relatively sizing stories AND estimating times for tasks. This could go either way – by overestimating to add “padding” or underestimating because the team hasn’t really thought through what it will take to deliver (they need to consider more than just size – complexity, risk, technical knowledge, etc. are also important to think about). At one extreme or the other – it just doesn’t work.
- No estimates/sizes at all
I’m not sure if it’s worse to have no sizes or estimates at all – sometimes this can be a sign that the team has reached the nirvana of Scrum, meaning they are so stable and predictable that they don’t need to spend time doing these activities because they all intuitively know what they can accomplish together. However, most of the time, this is not the case. When stories have no sizes and tasks have no time estimates, you’re sort of flying blind and have no way to measure progress (other than delivering a working product at the end of each Sprint).
- Burndown Going in the Wrong Direction
I like to see a Sprint Burndown chart follow the ideal trend as much as possible. It’s bad when it stays flat throughout a Sprint, but what’s worse is seeing the burndown go up, instead of down! This is a symptom that the team has added more items to the Sprint Backlog during the Sprint, they’re not burning down their hours on active tasks each day, or they have added time because they discovered something that they didn’t expect. When this becomes a trend, the Scrum Master might do well to question the team and challenge them to find a solution.
- Too much Work in Progress
While The Scrum Guide says nothing about limiting Work in Progress (WIP), this is an element of Kanban that many teams ought to adopt. Ideally, the team is working their way down from the top of the Sprint Backlog, focusing on the highest value/priority items first. But I often see that individual team members get stuck, and rather than working through their impediment or asking for help, they move on to something else so they’re not sitting idle. But once you start working on more than one thing, your time is split, and you start context-switching, which means you’re less efficient and it’s more likely that none of the things you are working on will get done. It’s all about focus.
- The focus is more on utilization than outcomes
Related to the previous item, many organizations still think the most important thing to worry about is utilization, or how much a person spends their time being productive. I find this silly, especially at this time in history. I really don’t care that every minute of every day is filled with some kind of work. For knowledge workers especially, people need time to think, and to worry about delivering a valuable business outcome – they don’t need to do non-value-added work because they happen to be idle.
- Team members work independently in silos rather than together
Scrum took its name from the game of Rugby. So, what does it mean to be a team? It means more than each person doing their individual component parts – it requires working together to get things done. A sports team would never, ever win if they worked the way a lot of so-called Scrum Teams do. It’s supposed to be a team sport – not an individual one. Putting multiple heads together usually accomplishes much more than just one.
- Constantly shifting Sprint Backlog
I like to think of the Sprint Backlog as a baseline against which to manage the change while a Sprint is in progress. Once the Sprint starts, and assuming you do have a Sprint Goal, the whole team should be focused on accomplishing that goal, but instead, interruptions and change (aka churn) keep changing the target, and as everyone knows, it’s very difficult to hit a moving target. Inasmuch as possible, the Scrum Team should self-regulate and limit any adjustments to protect their ability to reach their Sprint Goal.
- Stories that carry over time and time again
Talk about de-moralizing. When a Scrum Team has stories that carry over from Sprint to Sprint, to Sprint, it means that nothing is getting across the finish line. There could be good reasons for this, and often there are, but when this becomes a habit, it’s a symptom that something is wrong. It could be that the story was poorly sized (too big or complex), the person doing the work wasn’t competent to perform the work, or there was a fundamental lack of understanding of the request. No matter what the underlying reason, this doesn’t look good to your stakeholders, and it makes your team look bad. You need to stop, analyze the root cause, and find a solution.
Final Thoughts
So, there you have it – the first 10 symptoms that there’s something seriously wrong with your Scrum Team. I wouldn’t be surprised if you have seen one or all of these signs. If you have any tips or suggestions about what people can do to address these issues, please let me know in the comments below. And… stay tuned for Part 2, in which I explore 10 MORE symptoms that your Scrum Team is broken.