All right, you’ve had to wait a few days since Part 1 of this set, but at long last, here are 10 more signs and symptoms that your Scrum Team has gone astray and is broken! I know I started out saying this would be a two-part set, but I just keep thinking of more problems, so you might get a bonus blog or two on this subject, so stay tuned. Now, without further ado:
- Wildly out-of-whack work allocation
Have you ever seen those “special” team members who like to hog all the work or others who won’t volunteer to do anything? When you do Sprint Planning, assuming you’re able to enter team members’ capacity and track the task estimates against that, you should have a pretty good idea of who has taken on too much, and who will be sitting there twiddling their thumbs. This shouldn’t happen. The whole idea behind Scrum is doing work at a sustainable pace, and that means the work should be spread evenly across a team. Don’t let someone try to be a “hero.”
- Team members are only doing their specialty
Scrum is all about fully cross-functional teams, having all the skills necessary to complete a “done” increment at the end of each Sprint. If your team is filled with specialists and they can only do that one skill, you’re in for instant trouble. When you join a Scrum Team, you’re signing up to learn and grow outside your area of expertise and comfort zone. This helps lift the whole team up, and you become more valuable when you add new tools to your toolset. It also means that you can avoid the bottleneck that occurs when there is only one person who can perform a specific task.
- Unwillingness to learn to become more cross-functional
Related to the last item, if you’re not willing to learn new things, you might want to get a job somewhere else. Sticking stubbornly with only what you already know is a sure recipe for career suicide. One example is hitching your future to a particular technology or solution. Whether it’s Tableau, Salesforce, Figma, or whatever, if you can’t apply systems thinking to alternate solutions, you’re limiting your relevance. Companies get bought, sold, or acquired every day, and when that happens, there’s almost a 100% chance that the technology stack you need to work with will change. So, don’t get stuck being a specialist, become more of a generalist.
- Everything is a #1 Priority (which means nothing is a priority)
When you ask an organization’s leaders to prioritize the work your team is tasked with doing, can they definitively say which is the most important? Ideally, the items in your Product Backlog reflect the organization’s strategic priorities; if they don’t, you should ask yourselves “Why are we doing this?” Also, if your company says that everything is the top priority, by default, that means that nothing is the top priority. When this happens, teams end up getting tugged around like a tug-of-war and constantly trying to grease the squeakiest wheel. Instead, you should force the issue and reject items that don’t align with the overall organizational goals.
- People are being assigned work instead of volunteering for it
If your “manager” wants to keep you pigeonholed in your specialization, chances are that rather than being able to volunteer for tasks you want to tackle, they’ll be assigned to you. Controlling behavior like this effectively kills a Scrum Team’s chances of ever becoming a fully cross-functional team. Just because you are the best at a particular skill does not mean that you should be the only one to do it – nor does it mean you should stay comfortable and not volunteer for something that you’re not an expert in.
- A huge, unrefined Product Backlog
If your Product Backlog has too many items in it, it might be time to burn it down and start over again (not literally). When the size of your backlog becomes unwieldy and unmanageable, you need to get it under control. Start pruning – get rid of things that have been sitting at the bottom of the list for years. Throw away items that have already been addressed by other work. Pay down the technical debt you’ve accumulated, and then do your refinement on a regular basis so you don’t end up in the same situation again.
- The Product Owner doesn’t have the necessary depth of knowledge
If you are “assigned” as a Product Owner, hopefully, that means you are the subject matter expert and know the product and business inside and out. The best and most successful Product Owners I see usually come from the business. It’s also not a position that I would hire out – always look inside your organization first because there is probably a natural choice for who should take this role. The person must also really want to own it, which is no easy task. On top of that, they need to be aware of the markets and industries they serve. It’s a big job, and not one a newbie should take on.
- There are no stories or details
I have written about this problem more than once – it seems to be a recurring theme. Every item in your backlog should have a minimal description at worst, and the right level of detail at best. When there’s nothing there, it means that someone has the details in their head, and there’s no documentation. How can you possibly know that you’re meeting the requirements if you don’t even know what they are? There should also be some acceptance criteria – something that defines the boundaries of the story, so you know when to stop developing.
- Requirements are too detailed and specify the solution (paint by numbers)
The flip side of having no story or details is having too much information. This usually involves overly detailed specifications that often include technical details or solutions. I see this mostly when the Product Owner has a technical background – it’s just in their nature – but it’s not their job anymore. They need to communicate the business needs, and the developers are responsible for figuring out the “how” of the requirements. The P.O. just needs to supply the “who, what, and why” of the item.
- The team is not allowed to self-manage or self-direct
Middle managers usually don’t know what to do with themselves when Scrum Teams are formed, and they tend to want to stay in control, so they direct the work and try to control and measure it, rather than letting go and trusting the team to figure out the best way to do their work. When the team is disempowered rather than empowered, they won’t work well together, will be unhappen, and probably won’t deliver the best or more creative solutions.
Final Thoughts
There you have it – 10 more ways your Scrum Team can show signs that it’s broken. Have you experienced any of these issues? Are there any I missed? If so, let me know in the comments below! And you can also go back to Part 1 if you missed it.