Daily Scrum: Changing the “No Impediment” song…

Have you heard the no impediments song during the Daily Scrum?  

“Yesterday I did… Today I am going to do… No Impediments”

Everybody ends with “No Impediments”. I call this the “No Impediments” song. The Scrum Guide does not prescribe that these ARE the three questions that should be answered, it merely provides them as an example. But many teams use that as the default questions that need to be answered. Specifically, the example third question provided is “Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?” While it is not mandatory to use these three questions(and the dev. team can choose the format of Daily Scrum), many Dev. teams prefer to use them when they are getting started with Scrum.

As a coach and a facilitator, I would say that the third question can be modified and improved. Why? In its current state

• It is closed-ended. It is easy to answer Yes or No. Most of the times, the Dev. Team members answer No. And that is the end of the conversation
• Most often, unless the Dev. Team member is completely stopped from moving forward, they do not consider things as impediments. If they can work on a different PBI (which may not be the highest value add to the Dev. Team), they work on that and they do not have an impediment. You cannot blame them as the literal meaning of impediment is obstruction, hindrance or obstacle. Many times the Dev. Team or Scrum Master do not consider things that are “slowing down” the team as an impediment as some progress can still be made
• The framing of the question does not provoke the Dev. Team members to think about achieving the Sprint Goal in more creative ways 

So how do you change this?

I have found it useful to modify the third question when coaching new teams. Here are some variations.

• What is coming in the way of completing the top (product backlog) item in the next 24 hours?
• What one thing, if changed for me or for the team, will make us more effective in achieving the Sprint Goal?
• What is slowing me or the team down towards achieving the Sprint Goal?
• What accelerators do I need or the team needs to be more effective in achieving the Sprint Goal?
• What can I/we do differently in the next 24 hours to increase the probability of achieving the Sprint Goal?

Why do I find the above questions more effective? They are open-ended, not just considers obstructions (impediments) but also considers things that are slowing down the team.  Even if nothing is slowing the Dev. Team down, it provokes them to think creatively about achieving the Sprint Goal.

Ask the Dev. Team to try it for a Sprint or two, and then change it if it does not help. Experiment. Learn. Change. That is what empiricism is all about.