Organizational Impediment Management: Early Risk Detection for Agile

One of the many benefits of Scrum is early identification of roadblocks that could stop a Team from meeting their goals and commitments. At the Daily Scrum meeting, team members  typically answer 3 questions:

  • What have you worked on since we last met?
  • What will you be working on until we meet again?
  • What impediments are blocking our progress?

Many teams start with these 3 questions but then have difficulty not making this meeting into a status meeting for managers. The real focus of this meeting is to identify issues that could impede the Team’s current Sprint delivery commitment. We create burndown and other visible charts and tools to help us spot impediments early so we can respond more effectively.

In our Scrum courses, we make sure that Teams, and especially the ScrumMasters, know how to manage impediments for a Team. There are three main categories of impediments, each managed a little differently. 

  • Some impediments can be fixed by the Team themselves. Some of those are good to track for visibility to the whole Team. 
  • Some impediments are not entirely within the Team’s realm of control and therefore must be escalated so that management around the Team can help resolve them. ScrumMasters must find out how to get the correct folks involved and guide these impediments to resolution.
  • There is a smaller, but crucial set of impediments that are organizational in nature. They are bigger than any one Team and will involve changes in organizational policy, structure, or governance to resolve them.

It is important to adopt a communication plan that addresses how impediments will be managed and escalated in a scaled Scrum environment. In our consulting with organizations that have scaled Scrum teams, we’ve learned just how important effective impediment management at the individual, team, organization, and executive levels can be. When not handled well, the risk of not meeting date and budget commitments increases significantly.

Screen capture of "Add an Impediment" popup dialog on AgileEVM.com.

Given the importance of impediment management on dollars and dates associated with a release, we’ve enhanced AgileEVM  to manage impediments at the release, project, product, program, and project portfolio levels.  There are 6 attributes to an impediment that we have found useful to manage them effectively:

  • Impediment description
  • Importance of impediment resolution (Blocker, Critical, Major, Minor)
  • Action suggested to be taken (optional until impediment is assigned and understood)
  • Owner (optional until someone is assigned to resolve impediment)
  • Due date of when it must be resolved (optional)
  • Release it was identified in (optional)

When impediments are entered into AgileEVM, they are made visible on the “Impediments” tab for every level of the project portfolio.

Remember that using Agile methods such as Scrum do not solve your problems but they do make identifying them early much easier. Only through good communication channels and action do true improvements result from using Agile methods.

How do you manage your impediments at different levels of the organization?  We’re always glad to read your comments.

Be Sociable, Share!

5 thoughts on “Organizational Impediment Management: Early Risk Detection for Agile

  1. What would you think about making the Impediment visible with an estimate of its cost in $$. Then finding the Director or VP that has that $ level of signing authority to attend a meeting to discuss continue payment of the impediment. Until the impediment is resolved there is a continuing cost – get the VP to sign off on the waste.

  2. This has actually happened on consulting engagements we have been part of in the past, although not in the same way that you described. What happened, on multiple occasions, is the team(s) would identify risks to their release plans during a release planning session and then tell management how many days it would cost on the release plan ($/delay) if they did not have that risk resolved by a certain date. For instance, for every day we don’t have the dedicated server environment available it will add 3 days to the planned release date. We would have action items based on these risks to get them resolved with an owner and date that they commit to resolve them.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>