Note: I’ve written a post with my updated thinking on this point. I recommend that one; this one is mostly useful if you want to see history of my freaked-out thinking. 🙂
Our Project Management Department is making a role transition to Agile Coach from what is probably best described as Agile Project Manager. One of our top priorities has been moving away from the center of the fray. Where we used to serve as hubs of daily transactions, we instead now help team members solve them problems themselves, removing ourselves as unnecessary inter-mediators wherever possible. Impediments are one place where this is playing itself out. We had previously reached an extreme, where team members learned to rely on us to the point of their own helplessness, and we slowed the process both because of the inherent drag of bottlenecks but because we were the weakest link in the chain in terms of technical knowledge.
In many ways, things are improved. Requests that would take days to make their way through a telephone chain with me as central point now get resolved quickly. But now I wonder: where is the correct balance? How do we know when we have swung too far the other way?
Since in most cases in our organization Agile Coach translates to Scrum Master, I turned to the Scrum guide. There it is: part of the Scrum Master’s service to the development team is “removing impediments to the Development Team’s progress”. It does not say “removing impediments to the Development Team’s progress–providing that they are sufficiently daunting that removing them does not undermine the team’s sense of being able to solve problems on their own”. Do I turn around and intervene on every impediment? Certainly not; that just takes me back to my old habits as central operator. But how do I draw the line? At what point is an impediment large enough, hard enough to resolve, that I as Scrum Master step in and take the reins from the team? Maybe I handle an impediment that “blocks team for more than x hours” or “requires team member to contact someone outside the team”? Right now, I am seeing systemic benefits (greater autonomy, fewer bottlenecks, more efficient resolution, team growth) from letting the team resolve issues that cross both of the those thresholds. Or is the problem with my definition of “impediment”? Is there a difference between “impediment the team mentions at daily stand-up” (and that the team probably solves on their own) and systemic impediment (that is so huge and external to the team that I put on my change agent cape and go smash it)? Or maybe our organization has simply developed an extremely inclusive definition of impediments (“My pen ran out of ink, I’m blocked”), and that simply letting things go until “real” impediments arise is the answer. But if that’s it, how do I know a “real” impediment when I see it?
I don’t expect a formula. I know this will take case-by-case judgment, but the contradiction I see is so stark that I am having trouble making that judgment. Can anyone help me resolve this contradiction? Or come up with a rough rule of thumb? Or tell me how I have it all wrong?