Team member: How will we know when we've found an impediment? What do they look like?
Sponsor: How can I know what impediments block our teams' productivity?
Scrum Master: How can I get the team to mention impediments in our daily meeting and retrospectives?
Product Owner: Why is everyone whining about impediments? Why don't we just get the work done?
It's all fine and well to say identify and remove impediments but often we bump up against a stumbling block, find a way around, and make things work anyway without further thought. It's second nature. Moving forward is what's important. And, besides, those stumbling blocks? That's just how it is around here.
Recognizing and shining a spotlight on impediments isn't as easy as it sounds. At the Agile Roots 2009 conference Tom Perry led a session to do just that.
In his session, the participants (including me) focused on this question. We came up with a list teams could use to amplify their ability to recognize and manage impediments. Typical impediments fall into categories, including:
Incomplete work Missing information Repeated work Waiting Missing dependencies Interruptions Defects Bureaucracy Missed/Unclear communication Unmade decisions Faulty assumptions Insufficient time Missing parts Unknown new technology (contributed by @mxmoss)
...to name a few.
What kinds of impediments do you find?
Comments
The list here is helpful for categorization, but unless a team learns new techniques for seeing, these impediments will remain elusive. The practice of many Agile/Scrum teams to measure everything at a fine-grained level (e.g. hours on tasks) is more likely to hide impediments than reveal them. I wrote a post a couple of years ago on this topic: Surfacing Impediments By Doing Less: http://bit.ly/14p7Yd, recommending the use of visual tools coupled with a minimalistic approach to tracking to reveal previously hidden issues.
Thanks for the link, Tobias!
A good list, although I would venture to observe that these are symptoms of impediments.
What had a big impression for me in Jeff Sutherland’s keynote address at the Orlando Scrum Gathering was the statement that scrum teams should be removing impediments at root cause and not symptom.
For example, “Incomplete Work”; the symptomatic removal of the impediment might be to get someone to complete it. But if the underlying reason is a bottleneck for example, this impediment will continue to reoccur until the bottleneck is removed (usually by adding some more capacity).
Thanks for your comment, Carlo. Assigning a category label to a barrier to getting the work to done is not sufficient, as you point out. We must also conduct root cause analysis to get to the source, the reason behind the reason, in order to decide how best to remove them once we recognize they exist.
I note that the list looks like the list of common waste (muda) you minimize in lean development. Impediments could therefore be defined as “stuff that leads to muda”.
Muda can be found by using value stream mapping.
And removed by performing root cause analysis to see what in our process and organisation that leads to the waste.
BTW: thanks for the conversations we had last SDC in Gothenburg!
Hi Ola,
I agree with your assessment of the connection between many impediments and waste (muda). I’d say we need an additional step with the two you mention:
1) Find the muda (VSM is certainly one good path for finding it.)
2) Perform a root cause analysis on the creation of waste (and/or an appreciative analysis of where work goes on without this form of waste)
3) Identify and take ACTION to minimize or remove waste/impediments. (This may require a series of additional steps – Circle of Influence & Control analysis, identify “now” actions, plan for continuing improvement actions, evaluate actions, etc.)
Too often we forget the third step. ;)
Thanks, Diana