Thursday, April 26, 2012

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. 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: We need 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, a public impediment list, but we don't show the one that goes 'George picks his nose in the team room' or whatever example you want to use.

Yes, managers don't want to see a list of 'bitches and moans'.  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, some common sense....  But in general, more public, please. The more mature the firm, the more public.

Next problem I see: (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 them, 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 oh so true.

More broadly: They (the whole team) are not creative enough in identifying impediments. By making the list public, we can start to get more creativity.  Or at least see weaknesses in the list.  This is not anyone's fault.  It is just human nature. The pains you are used to no longer feel painful.  But we after 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.  But 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, at this moment, 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 top item.  And so on.  (The firm is investing in the SM to drive this.)  The team agrees to stop bitching and moaning about all the other stuff, and get some work done.  It's a much more functional deal than we had before.

Listened. 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. And can bitch and moan some more if a stupid SM does not understand HOW important their thing is.  (Sometimes the SM needs a bit of educating.  Who knew SMs did not know everything!?!?)  I won't add how it affects the motivation of the whole team to see the ordering of the whole can figure that out.

If there is a list, and the SM owns it, is he likely to focus more or less on that top item if the list is public?  I am thinking that visual management principles suggest that the distracted SM is likely to have a tad, just a tad, more focus if the list is public. (Ok, sorry if the sarcasm was a bit too thick. It helps, one hopes, fight through our rationalizations, and we all do that. So the sarcasm is directed at me as much as anyone else.)

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 as you suggested, I don't think human nature in the wild has evolved that far.

Now, as a tease, I will say that I am shocked, shocked that you don't want to be completely transparent.  Does that mean that we should remove the transparency idea from Scrum?

One final comment: I say, agreeing with you I think, that 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. But 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.

Now, to me an implication your 'daunting' concern is that we need some way to measure progress on the impediments. And I completely agree. 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).


No comments: