I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.
Some signs you may have a problem introducing a change:
- Taking action requires getting permission (this is straight from Pawel)
- Action can’t be taken because projects are too important to risk
- Only certain people can take action
I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…
Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.
The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.