What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on “Leading the Disruption.” He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go, or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question.

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productive.

I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

Anything that is slowing the team down compared to perfect productivity is an impediment.

What I have not seen talked about much is the scope from an end-to-end value stream perspective. So, I would argue that anything that reduces the Business Value of what the team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an “implementation” team in Chicago. (In this context, implementation means all those ‘services’ around the software that make it actually useful in production.) The Dev team completes their work. The implementation team is not ready (certainly not as ready as the runner to the right), so no Business Value can be realized.

I am suggesting this is an impediment — perhaps the top one for that Dev team — and that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that “a dead ScrumMaster is a useless ScrumMaster”). They probably can’t fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager’s help.

To me, this is similar to what Toyota found, i.e., that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc., etc.

Does this make sense to you?

 

« « The importance of Velocity || Up the creek without a paddle » »