Impediment Management

I was talking today with Martin Drapeau at PlanBox.com, brainstorming the question, “What do managers need?”

I have let the cat out of the bag: I am not one of those agile guys who thinks all managers are evil. (Yes, I have in my career seen more bad managers than I want to admit — not bad people, but “not-so-good” managers — and it is a problem.) In fact, I think some managers are quite good.

One thing we discussed is: How important is it to manage the impediments?

I say, typically, the first impediment is a lack of focus on removing impediments. I talked about this in a recent post.

What’s next? Well, I like to ask ScrumMasters, “Where is your public list of impediments?” All too often I get, “Ummm…” followed by a long pause, which is usually not a good sign.

Then I like to ask somewhat experienced Scrum people in my classes, “OK, how do you prioritize impediments?” Often I get “Ummm…” followed by a pause. You can guess by now that this is not usually a good sign, although they could be thinking about how to phrase it.

The simple answer for impediments is, prioritize the one that if improved or removed will increase the velocity of the team the most. The more complex answer is, “The one that gives the best cost-benefit ratio.” The benefit is the improved velocity (typically) and the cost is (mainly) the cost to reduce or remove the impediment. (Please apply the most uncommon thing: common sense.)

Do managers have a role? Yes, most assuredly, in removing impediments.

There is a management team (or should be) whose main job is removing impediments. I will call it the Impediment Removal Team — other writers give it a different name.

That IRT should see a list of impediments from all of the teams, and try to prioritize them across the whole group. Then, the IRT should organize the removal of the top impediment for the group — the IRT picks some appropriate ones to work on (ones that can be especially effective). All members of the “real” teams should see this, too.

Could a tool help here? Yes, after two or three teams, I think a tool could help.

So, for management reporting, would it be good to relate the impediments removed with the increased velocity? Yes, obviously, as soon as you ask the question, although how might be a bit of a problem. If managers had this info (and teams too), would it affect behavior in a positive way? I think so. (Yes, Virginia, it can be abused. Everything has some risks.)

Although we may have an IRT, we still have the (team) ScrumMasters driving the removal of the top impediment for each team (unless the IRT is working on that one, in which case maybe the second one). Again, the right people should fix each impediment. Right means they are available, they are good at it and they will do it (in a reasonable time frame). An impediment might be fixed by almost anyone: the ScrumMaster himself with his bare hands, the team (or part of the team) or people outside of the team.

Reminder: Do not do lots of management reporting. Too many numbers running around can be confusing, and not helpful. Only report what is useful — things that drive decisions and actions. Numbers never tell the whole story, but often non-obvious things that can be useful.

ScrumMasters, one of your biggest impediments is getting some managers to understand the new reporting and to use it well, operating from lean-agile-scrum values and principles. As some of you know, this can be very hard work for you.

Make sense so far? Your comments are wanted. Please comment. I will have more to say on this topic shortly.

Facebooktwitterredditlinkedinmail

« « Complex Adaptive Systems || The Unbearable Lightness of Being » »

2 thoughts on “Impediment Management

  1. Vin D'Amico

    You're correct. Impediments always exist. They may be small and merely an inconvenience or they may be large and expensive. A good Scrum Master must devote significant time to identifying and clearing impediments. The impact on velocity can be huge.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *