Impediments - hidden or otherwise

A comment to my post on “Three ways to run a stand-up meeting” asked: “Can you give an example of the ‘hidden’ impediments?” so here goes.

First: know the difference between a block and an impediment. A block stops all work, they are seldom hidden because people can’t get on with what they are doing. A impediment is something which gets in the way, slows you down, saps your morale.

Fortunately, or maybe unfortunately, software people are very good at routing around blocks. They find ways to “get stuff done” even if it is not the best way, the fastest way, or the “right way”. So blocks often become impediments. Unless we strive to impediments our teams will not perform to their maximum.

One nasty form of impediment is the “I’m blocked so I’ll make work to look busy.” The work which is created is seldom as valuable as that you are blocked from doing and even worthless.

Anyway, examples of impediments, especially hidden one:

• Vendor is not responsive: someone is waiting on a vendor to deliver something and it isn’t happening; or you are waiting on a vendors technical support, or perhaps you need information from the vendor before deciding whether to use their product or someone elses.
• Build problems: the build is broken, or you need someone else to fix their bit, or you are waiting for access rights, or the compiler seems to have a bug, or ... the list goes on
• Waiting on another team: particularly test, source control, user interface, tech support, etc. Idealy we want each team to be vertical, that its, to be self sufficience, to contain the skills and authority to get a job done without needing action from others. But this doesn’t happen as much as it should so you need another team to do something. At this point problems occur because the other team doesn’t have the same prioirities as your team
• Upgrading compiler, OS, app server, etc: some piece of software (or perhaps hardware) needs to be upgraded. So instead of getting on with the task in hand someone is diverted to upgrade the system. And when this takes long than expected, or hits problems, then it becomes an impedimant and even a block.
• Bug - typically in a library: you can’t get on with your own work because of someone elses bug. Ideally you can just jump into their code and fix it but.... if the bug is in a third party library then it not quite so easy. And if the problem is with the compiler, or a vendor you get to one of the problems above.
• Database changes: databases teams seem to work in a completely different temporal dimension . Too often I meet teams who can’t progress because a DB schema change is needed, or the meta-data is a problem, or .... The real solution is two fold: simplify designed and reduce the need for complex databases, and ensure the team has database skills itself.
• Waiting on a management decision: all too common, management can’t make their minds up whether to do it like X or like Y. A particularly nasty version is when you’ve asked for something “Can we buy Z?” and rather than say “No” you are kept hanging on. If they just said “No because...” you could address the reason or find another way of doing it.

When team members can’t report real achievements in a Scrum meetings they usually report ”what they have done“ which includes ”why there isn’t an achievement“. Thats the point at which these kind of impediments are mentioned. A good Scrum Master / Meeting Leader / Agile Coach will spot these issues and move them to impediments.

If you have any more examples of impediments please add them as comments below.