Scrum defines an impediment as "anything keeping the team from being more productive" and clearly stresses that teams establish means to remove them as continuously as possible. Joe Little proposes an impediment's scope may be better established as being anything keeping the organization from delivering value.
In a post early in the week Little posed his thoughts on why velocity is an important metric to an agile team. In short he points out three items:
What Little is saying hits on the fundamental premises of the systems-thinking characteristic of Lean software development made popular in recent years by Mary and Tom Poppendieck, Kenji Hiranabe, and others. In short, the message is to prevent localized optimization by understanding your overall value-stream and removing impediments wherever they may land on it.
In a post early in the week Little posed his thoughts on why velocity is an important metric to an agile team. In short he points out three items:
- Defense: Velocity gives the team legitimate ammunition to say no (or yes) to managers and customers
- Justification: Velocity metrics help manager's more comfortably accept explanations of why agile is important
- Challenge: Velocity gives the team a bar by which to gauge efforts to remove impediments
By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And 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.Little follows with an example of a development team whose building software that their partner "implementations/install" team is not ready to install. In this case, the team's DONE, but zero true business value has been realized. Little's assertion is that the implementions hold-up is the most important impediment and that the development team would be wise to put some energy into seeing it removed.
Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.
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.
What Little is saying hits on the fundamental premises of the systems-thinking characteristic of Lean software development made popular in recent years by Mary and Tom Poppendieck, Kenji Hiranabe, and others. In short, the message is to prevent localized optimization by understanding your overall value-stream and removing impediments wherever they may land on it.
