Scrum bad smells
There are a number of “bad smells” that you might encounter while doing Scrum. These are generally signs that might seem innocent, but suggest something is badly wrong. You need to watch out for these signs.
Standups going over the timebox
The bad smell
This is a classic one to watch out for. The Daily Standup is generally timeboxed at 15 minutes, and it should ideally go for a fair bit less than that. In fact, I like to see them done in five minutes, ten minutes at a stretch. A standup that regularly drags on is actually a pretty bad sign. It usually indicates one of two things: personality clashes in the team (people bickering over who is working on what or what approach they are taking to working on a story), or a total lack of communication between the team during the rest of the day. The former is easier to spot. The latter points to broader and deeper social dysfunction.
Another rare but possible cause is a large turnout of “chickens” to the standup (read this if you’re not sure what I mean). Chickens are allowed to attend, but they are not allowed to speak! They can only observe. So if a lot of chickens are turning up and asking a lot of question and making a lot of comments, you need to have a gentle talk with them. And remind them that they are not part of the team and cannot directly participate.
How to fix it
Enforcing the timebox seems like a simple fix, but it is attacking the symptom, not the cause. Social issues or communication problems in the team can be tricky. I would recommend a retrospective dedicated to resolving this, but facilitated by someone outside the scrum (another scrum master or coach from another area). Doing that can help if people feel the scrum-master has “taken sides” or is biased.
Poor attendance at Sprint Reviews
The bad smell
Everyone in the scrum needs to attend this important ceremony. And sprint reviews should also be attended by some other stakeholders or interested parties. If you’re only getting a couple of people and some tumbleweeds, there’s a big problem: nobody cares about the team’s progress (the sprint review). This points to either a demoralised team, aloof and uninterested stakeholders, or sometimes both.
How to fix it
This one is a bit tricky. Again, you can just remind everyone that the have to turn up, but this is not attacking the root cause. This points to a culture and morale problem. Try to find out what the team thinks of the product and the roadmap. See if they buy into “the vision”. If they don’t, the product owner probably has some work to do in boosting the morale of the team for the product.
If you are finding stakeholders are not turning up, that’s a bad sign also. It means they either don’t trust or care for the product (which will not help its chances), or they don’t trust or care for the Agile process. Try talking to them and encouraging them to come. Remind them it is a wonderful opportunity to regularly inspect the product. Remind them that it lets them see what they are getting for their money!
Chaotic Sprint Planning meetings
The bad smell
We’ve probably all been in one of these. A long and chaotic sprint planning meeting, where people try to figure out what these user stories are all about. Lots of shouting and questions and arguing. It doesn’t have to be this way. This is a sign that the scrum is not managing their backlog properly. The truth is, sprint planning meetings should be pretty short and simple affairs. The scrum guide says they should go for four to eight hours; I think that’s ridiculous. And people want to kill each other after a few hours in any kind of meeting. I try and get them done in one or two hours. The trick is to be prepared by refining the backlog.
How to fix it
This is a sign that during the sprint, the product owner is just stuffing random stories in the backlog, without much explanation, and without telling people what’s going on. Spring Planning should be a “no surprises” zone! If the team looks at the backlog and say “what is that story? I’ve never seen or heard of it before”, that’s your problem right there. This meeting is about agreeing how much of the work to do and the way it should be done. It is not about discussing what the stories are and how they relate to the product.
I recommend a mid-sprint Backlog Refinement meeting, where the product owner can describe some of the stories they would like to see go into the upcoming sprint. This not only gives the team time in that meeting to ask questions, refine and discuss the stories, it also gives them time for the rest of the sprint to further understand and refine the stories. Maybe do some spikes or research. Maybe sketch out some prototypes with UX. So that when it comes time for sprint planning, the stories are well understood. Trying to jam all of that into one long meeting is painful and counter-productive.
Sprints that change dates or cadence
The bad smell
The team sometimes stretches or shuffles sprint dates around, usually to accommodate overdue or late user stories. Or the team randomly switches cadence, from a two to one or three-week sprints, for the same reasons. This is usually a sign that the scrum is changing the sprints to accommodate the work, instead of the setting the work to fit in the sprint. Having a regular cadence improves planning and predictability. If you have short sprints (one or two weeks), then a user story missing a sprint isn’t much of a big deal. And if you have Continuous Delivery, done properly, then the sprint boundaries are less meaningful anyway, and you can deliver that late story early in the next sprint anyway.
How to fix it
Be tough on your sprint boundaries. They don’t move. Lock them in with other teams so you’re all following the same cadence. That makes is harder for one team to shift, since it will put people out of lockstep. If it’s still a problem, make sure to leave some “buffer” time or capacity, i.e. only plan for about 80% of the work that you think you can do in a sprint, so you have wiggle room to accommodate more. Remember, any system that is at absolute full capacity is not efficient, it is strained and in danger of choking and slowing everything down. You need to leave some slack.
No software at the end of the sprint
The bad smell
The team is doing “work” and completing “stories” each sprint, but there’s little or no software to be seen. The team is producing documentation, or APIs, or database changes, or busy on giant stories that can’t be seen or tested or interacted with for many more sprints to come. This is sadly a common smell, especially with large enterprises trying to suddenly “do agile”.
How to fix it
There probably a number of problems here. To start with, make sure you have a cross-functional team that can build all the components needed to deliver a piece of valuable, functional software within one sprint. It doesn’t have to be amazing or change the world, but it has to be something meaningful for a customer. Even if it’s just a password strength meter. Also, make sure you are breaking your backlog into small user stories that can be completed in a few days. And make sure each user story represents a piece of software. Documentation, stubs, background images, these are all important parts of software development, but they are tasks. They are not user stories. Which brings us to the next smell…
User stories with no business value
The bad smell
The team has a nice big pile of user stories, but none of them seem to describe real software providing real value. There are “technical user stories” (watch out for these, they’re a bad idea), lots of user stories for “setup work” or prototypes and spikes, user stories for non-software tasks like documentation, or even worse, for things like “meetings”. This is sadly a common practice.
How to fix it
There are two reasons for this practice. The first is that the team doesn’t understand how to break up user stories, or is not a cross-functional team. Maybe it’s a team of UX designers or Database Administrators. It is impossible for such a team to completely deliver valuable working software, which is the reason you should have cross-functional teams. The other reason is that the team doesn’t understand the concept of points and velocity. They think points are “gold stars” that should be awarded to the team for doing anything at all. If the team spent 100 hours last sprint in training and meetings and delivered no software, they should be given lots and lots of points for that, because all that took a lot of time! And we should get points for it! Well of course it took time, but it should be worth zero points.
The purpose of velocity is for the team to understand it’s current average rate of delivering software. If the team is spending no time on delivering software, that should be urgently acknowledged and made visible, by showing zero velocity. Points are not gold stars, they are a representation of progress towards a sprint goal and a release goal. And those goals involve the delivery of valuable tested software. This is similar to the reason why you shouldn’t get points for fixing defects.
I hope you find these bad smells helpful! Can you think of any other bad smells and potential fixes? Please let me know in the comments!
