Public Impediment List – Again

I wrote the following post to a Scrum group. Perhaps you will find it interesting. It is lightly edited. And it is in response to another person’s post.

***
Let’s talk about the impediment list more.

Along the way I will mention some of the problems I see in real life.

I find that most ScrumMasters don’t have a list of impediments, even in their head.  And it leads to a low level of activity (bordering on none, much too often) in removing impediments.  One example of what they typically should have is: Better engineering practices (add XP things, one at a time).

I agree of course that not every impediment can be put on the list.

In Scrum we are working both with and against human nature. Yes, I agree it is human nature to want to hide. And yes we need transparency to be better.  So, the solution is some common sense. More transparency, but we have to be reasonable.

So, for a public impediment list, we don’t say ‘George picks his nose in the team room’ or whatever example you want to use.

Yes, managers are skeptical of a list of ‘bitches and moans’.  And they don’t want people saying ‘your kids are ugly’, …meaning: If I as a manager put in place Process X, I don’t like it when some team calls it an impediment.  Again, we use some common sense….  But in general, more public, please. The more mature the firm, the more public.

Next problem: (expressed in this metaphor)  There is a table with rolling wheels under it. And beside the table a movable wall, also on wheels.  You and I would say they are both impediments. I see far too many teams not even identifying them as impediments (the table and wall in my metaphor). When shown, they say: Well, it would be impossible to (re)move them. We point out the wheels. They say: Well, still impossible. Only when we actually move them ourselves, does something happen.  Weird, but too true.

More creative. More broadly: They (the whole team) are not for a while creative enough in identifying impediments. By making the list public, we can foster more creativity.  Or at least, see weaknesses in the list.  This is not anyone’s fault.  It is just human nature. The pain you are used to no longer feels painful.  We overcome human nature (or parts of it).

Pareto. As with any work, there are a few items with the real juice, and lots and lots of relatively minor things. We must Pareto-ize the list. Prioritize it; order it.  Just like the Product Backlog.  We need a good list first.

Ordered? Yes. There are dependencies in implementing better engineering practices, for example. These need to be shown in the ordering.

Social Contract.  The Impediment List is like a social contract.  I will say, for now, between the firm and the team. The firm agrees to fix, within some reasonable constraints, the top item on the list.  And then the next item.  And so on.  (The firm is investing in the SM and the Team to drive this.)  The team agrees to stop bitching and moaning about all the other stuff, and get some work done now.  It’s a much more functional deal than we had before.

Listening. We need the list public so each member of the team knows they were listened to.  Only if they see ‘their baby’ on the list, do they know it even got on the list.

Discuss and clarify value.  We need the list public so that each person can see where ‘their baby’ was ordered.   I won’t add how it affects the motivation of the whole team to see the ordering of the whole list…you can figure that out.

Focus. If there is a list, and the SM owns it, is he likely to focus more on the top item, if the list is public?  I am thinking visual management principles suggests the distracted SM is likely to have a tad more focus if the list is public. (Yes, a bit of sarcasm.)

Those are my main arguments for a (mostly) public impediment list.

Of course, if by magic always the top impediment is being removed and everyone is otherwise completely happy, then I am a practical guy. If life could not get more wonderful, screw the impediment list. In fact, let’s forget about scrum.

But I don’t think human nature in the wild has evolved that far.

Now, as a tease, I will say that I am shocked that [a person against the public impediment list] doesn’t want to be completely transparent.  Does that mean that we should remove the transparency idea from Scrum?

One final comment: the impediment list never ends.  Since nothing we do is ever perfect, everything everywhere always needs to be fixed (improved). So there is an endless job for the SM. In fact, most Super Bowl winners can’t even repeat the next year. So, yes, it is a hard job, daunting, and it takes courage, that is just the truth. I could lie to you, and say life’s a beach and growing old is completely easy.  Would that help?  Sufficient unto the day is the top impediment thereof.  Just work on that one.  That is not so daunting.

So, after maybe 20 items on the list, I am not sure we need a longer working list. Then order the 20 or so items. As some are fixed, add more items to the list.

Some people worry that a list of 20 impediments would be daunting.  I do not find this argument compelling.  But it does have some basis.

To address the issue, we need some way to measure progress on the impediments. Most mere mortals need some encouragement. And at least looking back, sometimes, at all the impediments thrown out of the path is satisfying and reassuring.  There could be other ways too….but we need to start with a (mostly) public impediment list.

I await your comments (and others’ too).

Thanks,
Joe

 

« « What cocktail parties teach us || Referral Program » »