Do we need an Impediment List? Yes!

July 26, 2013

Yes, we need a public impediment list. Every Team does.

Why?

One argument against is that all impediments should be eliminated immediately.  Yes, if this were possible, this should be done.  But I think that assumes an incorrect view of what impediments are.

Yes, it is true some impediments only appear from time to time. If  you only get small ones at rate that you can fix them all the same day, then ‘fix  immediately’ is the right answer.  No list is needed. (Well, honestly, even then I would need a short list.)

But I think we should have a totally different attitude toward impediments.

As with Lean, we should give ourselves the ‘perfection’ challenge.  That is, we do not indulge in the fantasy of becoming perfect, but challenge ourselves to strive toward perfection.  More concretely, to become the best Scrum Team ever.

So, an impediment is anything that can be improved, leading us to become (we hope) the ‘perfect’ (best) Scrum Team.

Of course, nothing around us, and nothing we do, is perfect. So, everything needs to be improved.  Even Michael Phelps can swim a better race.

Then the public impediment list really should be the top 20 things we should fix now. (If we listed everything, we might have 900 items, but in this work, it helps not at all to have a list of 900.  Just the top 20 will do for now. A shorted list is more helpful.)

Impediments can be anything — anything — that is keeping the team from being perfect. Missing fun, blockers of stories, people issues, slow CI, managerial interruptions, task-switching, poor organizational incentives, bad user stories, weak PO, waterfall culture, lack of babysitter, Scrum not fully implemented in the organization, lack of urgency for change, bad corporate culture, a culture that requires hiding any ‘failure’, etc, etc, etc.  Anything. Of any type.

Also, some impediments are quite difficult to fix.  Might take time.  Might need to be broken into parts.

In my experience, many obvious impediments are begging to be put on the list, but people pretend the ‘elephant’ is not there.  In part, because no one gave them the notion to start a list.

Lastly… Some complain, rightly in some cases, that an impediment list implies inaction on the impediments.  Of course, the purpose of the list is NOT to stop action on fixing or ameliorating them.  The list is supposed to help us attack the impediments.

So, have a list. Attack them. Aggressively.

 

Facebooktwitterredditlinkedinmail

« « Impediments (or symptoms of) – Montreal Class July 2013 || The ScrumButt Test (2): Working Software » »

Posted in: agile business, impediments
Tagged: Tags: , , , ,

2 thoughts on “Do we need an Impediment List? Yes!”

  1. Hal Macomber

    Hi Joe,

    In the Lean construction community we use the term “constrain” for anything that would keep you from starting and finishing a work item. The term comes from Goldratt. Constraints (blockers) need to be removed before the work is ready.

    Your use of “impediment” expands on the opportunities for pursuing perfection. And, of course you need a list; some items that impede take time to address.

    ↓
    1. Joe Little Post author

      Hi Hal,

      Glad you mentioned that.
      You have not quite said this, but…

      The best way to attack impediments is with an understanding of TOC (Theory of Constraints).
      And for those less familiar with Goldratt, the basic idea is quite simple.
      One way to express it simply and quickly: Imagine a linear process. Imagine that you don’t fully understand the process, but you do understand that each part of it has different levels of constraints (or at least, sooner or later we discover that). So, we pick the most constrained step to fix. And, once fixed, we have to re-evaluate the whole process to (re)discover the (now) most constrained step. And often we are surprised. But usually the MOST constrained step at any one point in time is rather obvious.

      So, if we remove impediments in that way we, the Team, will probably realize more improvement sooner. (Than fixing things in a different order or way.)

      I want to emphasize: Impediments are anything SLOWING DOWN the team. It does not have to STOP the team (can’t start or can’t get to finished). An impediment might only slow us down. (“We feel like we are walking through mud.”) (I doubt Hal that you would disagree, but I worry that others might take your words a different way. As I have seen in the past with other words.)

      I don’t teach TOC in the beginning. I just want to get the MOST basic things going:
      * admit we are not perfect
      * identify some good impediments
      * get someone to work on them aggressively, one at a time
      * get some measurement of improvement (eg, sometimes we think we have improved something, when in fact we made things worse).

      I am still a bit shocked that so many so-called “Scrum” teams don’t have an impediment list. How can one (eg, the SM) be effective without a list, and then a list that is managed well???

      Hence, I talk about this key, very very basic issue all the time. But having a list is useless unless you take the next steps too.
      Thanks, Joe

Leave a Reply