Stupid Impediment Tricks – 1

I wanted to review some “obvious” ideas about impediments. Here’s a starting blog post on that theme.

No problem is the problem.

A lot of teams and people want to have the idea that they are “as good as it gets,” and it may be true that they are very good.

In the Lean community they have this phrase, “No problem is the problem,” and it often is the first problem. That problem comes in several flavors: We do not see any problems. We do not wish to admit to any problems (e.g., we might be punished). We do not see the value of talking about problems (e.g., we do not think anything will be fixed or any benefit will arise).

An impediment could be any kind of thing.

A lot of people have the mental concept that an impediment must be of type x, y, z. For example: They can only see technical impediments, or impediments are only things that block specific stories (a.k.a. “Blockers”).

But this is incorrect.

An impediment is ANYTHING that is slowing the team down in any way (or stopping the team). Some diverse examples:

• Company culture
• An organization structure that is no longer useful
• The blame game
• Insufficient automated testing
• A weaker than needed continuous integration process
• Lame coding standards
• Lacking ready-ready criteria
• Poorly remembered vision
• Negative Nancys (sorry Nancy)
• Tyrell Owens (OK, a non-team player on the team)
• The servers are crashing too much
• Too many distractions (I have given up on the idea of completely eliminating distractions, nice as that would be)
• Lack of baby sitters (for those members of the team who need them)
• Too many re-orgs

You get the idea I hope. Anything that is slowing down the team is an impediment. It is impressive how anyone could easily leave out a certain category of impediments. It is human nature to do that, I think. Try to overcome that problem.

We need an impediment list.

One idea is that any impediment should be fixed immediately. This is a good idea, except that it is impractical. No one (not even Hercules with his 12 labors) could possibly clean out that Augean Stables so quickly.

For example: Company culture. But there are many more. Getting automated testing to be as good as it should be will take time, and a breakdown into smaller tasks.

So, we have a list.

Next, the impediments (the list of that work) must be prioritized. People always complain about everything. Usually, to some small degree, they are right. If this coffee were hotter, I would not be complaining about it and I would get more work done.

But a ScrumMaster cannot re-heat every cup of coffee. From a priority viewpoint, that it just not common sense.

So, for the top 20 impediments, the team and the SM must get them prioritized, and the SM should work them in priority order (I really mean ROI order mainly).

 

« « The Agile Challenge – Success criteria || A resource for Business Analysts » »