…I have no impediments.
If you have worked in scrum, you know this is the team member signal that they are done in most daily scrum meetings. Its nearly the safest bet in the world of agile, each member will more-likely-than end their 3 questions with this statement. And it is understandable, it tends to become a cultural pleasantry like when someone asks “How ya doing?” or “Did you have a good day honey?”. We dismiss the question in whole, just because its part of our repertoire.
But here is the thing: the daily scrum is not a cultural pleasantry. The scrum is an opportunity for the team synchronize, reflect and learn. If a team member has or had an impediment, they owe it to the rest of the team to acknowledge it. If you are blocked, trust your team to help you overcome the issue so your collective progress is not impacted. Even if you cleared your own impediment, mention what it was, because it may effect others.
I coach scrum masters to be alert for the “I have no impediments” regularly. The reflection on what is slowing a team member down is as important as what they have accomplished that day. Maybe a small impediment faced by one developer seems inconsequential, but that same issue scaled over a full team has a sizable impact on the overall team velocity.
Acknowledging impediments is not the same as saying “I am incapable, and need someone to fix something for me”. There needs to be a sense of safety within the team that impediments are seen as learning opportunities when they can be fixed within the team. Equally important, when an impediment is something the team cannot fix, and it is an organizational or external issue, the team must raise this to the PO, the scrum master, the manager, the director, whoever can remove the progress blocker. Not speaking to issues enables them to continue and perhaps compound.
How does the scrum master correct this?
Make no mistake, identification of impediments is a team member task. It should not be the scrum master’s role to consistantly pull impediments from team members. If this is the reality of a team, there needs to be reset, coaching exercise or perhaps more invasive retraining. However, if a team hits a period where impediments are not being discussed, they should gently ask some observational questions such as:
- How have your code reviews been recently?
- Do you have any access issues?
- Is there any opportunity for two members to pair on this stuck task?
- If we had a free resource to help, what would they work on next with you?
- What could be done to get this story done sooner?
These questions need to be asked in an environment that is non-accusatory and safe. The intent is not to condemn any team member, but to have them self realize there are impediments every day, we just need to acknowledge them so that we can learn.
But here’e the rub…
When a team starts to acknowledge impediments regularly, there will likely be a natural inclination to try to solution the impediment on the daily scrum. The scrum is not the place or time to solution. Take note of who has interest in assisting, and have a break out session shortly after scrum so the context is not lost. What is equally important to solving the issue is radiating what was learned. Sometimes this is solved with a comment in code, a config change, a wiki/documentation update or perhaps something as simple as a team communication in the next scrum. Its situational, but not sharing what is learned is tantamount to mutiny in scrum. :-)
Images used by permission from Jurgon Appello and Management 3.0
