5 reasons your Daily Standup isn’t working Most Agile teams have Daily Standups. How do you avoid the most common pitfalls?

The Daily Standup is a great opportunity for teams to inspect and adapt on a daily basis. The guidance from the Scrum Guide on the daily event is rather straight forward:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

The Scrum Guide also gives us three important clues for what you want the team to share in the standup:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The terminology can be more generic by substituting the term Sprint with a more generic term like iteration, but other than that these three guiding questions works in settings outside of Scrum as well. Although the guidance seems quite simple there are a lot of common mistakes when doing the standup:

1. People show up late or don’t show up at all
Waiting for someone to show up is most likely to be wasted time and the opportunity to fully inspect and adapt won’t be realized if someone doesn’t even show up. It’s important, however, for the team to realize the importance of the event. The problem is a team problem and there are probably a lot of different solutions to it. One common way to try and solve this is by having some sort of punishment for being late. Having incentives for showing up on time is also a good idea. This could work, but then again it might not. A person consistently showing up late might have something outside work blocking them from making it on time; like f.ex having to drop off their kids to kindergarten or school. In that case it’s just going to hurt moral for this person since he/she has external obligations that can’t just be dropped. A better approach here might be to move the standup, so that everyone can certainly be there on time. Communication is important, so the team should figure out the best solution for their particular context.

2. The standup turns in to a status meeting
This must be one of the most common pitfalls. Only the two first questions of the three stated above are answered. In all earnest the first two questions might not even need to be addressed in a team that is working closely together. What was done yesterday and what you will do today may also be seen on the teams task board. Through pair or mob programming it follows that the team most likely know the answer to these questions already. This might in fact also be the case for the third question about potential blockers. However, both pair programming and mob programming is not something every team does – so the third question, the most important question for inspecting and adapting, really should be the focus of the standup. Only answering the two first questions turns the standup into a status meeting, which the standup is not supposed to be.

3. Problem solving and removing of blockers
Although the question about blockers is the most important one of the three in the guidance of the event – don’t try to solve these things during the standup! Instead a simple “I can help with the issue” from someone else is enough and the issue can be handled outside the standup. People are generally busy, so don’t involve everyone in everything. Of course, this doesn’t work so well if no one actually offers to help out – but in a self-managed team this shouldn’t be an issue.

4. Too much details
The three questions makes for excellent guidance. Once people goes outside those questions theres a good chance too much details will be communicated and people just ramble on. If you really have something more you would like to share – choose another opportunity to do so. If it’s really important information you could ask people to stay behind after the standup or just talk to the team when you get back to your team area. Too much details easily leads to too long standups – and engagement goes down. Also – people could stop really listening to what you say.

5. People are not really listening
If the standup is conducted such that the order of speakers is the same every day and the person leading/facilitating the standup is the same every day – people tend to stop listening, just awaiting for their turn to deliver their message. Also, if it’s the same facilitator every time people tend to start talking to the facilitator rather than the team, which only enforces the incentive to stop listening. As mentioned above – too much detail can also lead to less active listening. To effectively be able to utilize the standup for inspecting and adapting we need the whole team to actively participate – continuously looking for improvements. Some simple ways to mitigate this issue is to mix up the facilitator role – don’t let the Scrum Master be the one who always facilitates this event. To prevent the same pattern for who speaks a simple randomizing algorithm probably should be used. Passing a token (throwing a ball) or in the order of arrival could work. Probably some online tool for randomizing order exists. Experiment and don’t do the standup exactly the same way every time.

The daily standup shouldn’t be complicated and the guidance with the three questions that need to be answered is simple. If you get people to show up on time and mix up the order of speakers and facilitator the standups should be working. If they still don’t work for your team and the team questions why you are having them the team has to dig deeper. In teams with a high degree of pairing or using mob programming the standup might even not be needed. Through continually inspecting and adapting the team should discover and take actions to improve. Is your team doing that?