You’ve trained your new Scrum troops, and they’re ready for their first mission. The team is pumped, and the project is up and running. Things are going well; the daily scrums are happening, the continuous integration server is humming along, tasks are moving across the board, so life is pretty sweet. Then, from out of nowhere, the bullets start flying, the mines start exploding, and your troops are no longer moving forward. This is it, ScrumMaster—time to step up!
Okay, so perhaps in reality, it isn’t a spray of enemy fire impeding your team. Instead,it might be a constantly breaking build, an interfering project sponsor, or perhaps the loss of a key team member. The bottom line is that anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle.
Defining Impediments
Let’s start by defining what an impediment is. Here is the definition I choose to use:
An event that impedes any of the developers from working to their anticipated sprint capacity.
If you recall from my article about sprint planning, it isn’t wise to allocate a full-time developer a sprint capacity of 8 hours a day (for a typical 8-hour working day). Why not? you ask. Well, you have to be realistic: there is no way that people are going to spend every second of their operational time working on their sprint tasks. We must take into account the various meetings that will pop up, other extended collaboration time, unplanned company events, and important head-clearing breaks, just to name a few. Now don’t get me wrong: on some days, some team members will be able to maintain strong focus on their sprint tasks and will max out or even exceed the 8 hours. However, on other days, constant interruptions may make it difficult to maintain even a couple of hours of sprint-focused work.
Many Shapes and Sizes
Impediments come in all shapes and sizes. Following is a small sample of indicative impediments (both operational and systemic) to keep a careful eye on:
- Meetings of large magnitude: Scrum projects really should have no need for these extraneous, long-winded bad boys, so when they pop up, they are typically triggered by other areas of the business or by unforeseen issues.
- Illness: Illness can strike unannounced at any time. Not much you can do about it, but I highly recommend you avoid a culture of “toughing it out” when sick. That expectation is just stupid. Work quality suffers, germs spread very quickly in an open Scrum environment, and it just annoys everyone.
- Broken builds: Without a healthy build, development cannot continue. If a build is broken, it must be the top priority of every team member to fix it.
- Issues with the tools of the trade: Whether it is a hardware malfunction, software problem, or network connectivity issues, any problems with the working environment can seriously hamper progress and lead to immense frustration.
- Unreliable supplier: This is possibly one of the most frustrating impediments due to the lack of control that the ScrumMaster and team might have in dealing with an overburdened supplier. Poorly supported components or add-ons can lead to black holes that can seriously suck time from your sprints.
- Unrefined product backlog: A sprint should never start without the product owner knowing exactly what requirements should make their way into the sprint backlog. Further, these requirements should include enough detail for the development team get their teeth into. If these requirements are not ready for the sprint planning session then the sprint will not start smoothly at all.
- Absent or unempowered product owner holding up key decisions: Product owners should be available throughout the sprint to field specific questions about the sprint backlog. If they are regularly absent or constantly having to seek approval from elsewhere, the development team might find itself paralyzed with uncertainty.
- Incentive schemes focused on the individual: Many organizations maintain performance reviews (and associated incentive schemes) that are based entirely on individual performance. Hopefully by now you’ve absorbed the fact that there is no “I” in “Scrum team,” so unless reviews also incorporate a significant focus on team collaboration, the organization will be sending a contradictory message to the team members.
Impediment ConTROL
I like to run through the following five-step approach when dealing with impediments: confirm, triage, remove, outline, learn (ConTROL).
- Confirm: Obviously it is necessary to confirm what the impediment is. Typically, impediments are raised in the daily scrum, but urgent impediments should be raised in real time rather than waiting for the daily scrum. The sprint retrospective can uncover further impediments that may have slipped through the cracks during the actual sprint. All impediments should be tracked and monitored until they are resolved.
- Triage: If you are bombarded with simultaneous impediments, then unless you are Superman (being obsessed with super heroes doesn’t automatically give you their special powers), you will be able to tackle only one or two at a time. An impact and urgency assessment may be needed to help you determine where to start.
- Remove: Ideally, the Scrum team can remove any impediment that gets
thrown its way, but it isn’t always the reality. To avoid delays, it is important to know when to seek further help from other groups to get things back on track (see Chief ScrumMasters and ScrumMasters). - Outline: Both the Scrum team and stakeholders should be made aware of any impediments as they come up. You especially want to avoid surprises for product owners (and project sponsors) when it comes to any scuttled plans so that they have as much time as possible to iron out any cascade effects.
- Learn: The sprint retrospective is the main session during which impediments are analyzed. It is important to learn from these issues to avoid their recurrence and/or capture how they were dealt with so that if they strike again, the impact is less pronounced.
Blocks versus Impediments
Many teams use the terms block and impediment interchangeably, but I like to differentiate between the two (see Figure 1). I do so to clearly identify an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment).
A typical block occurs when a task has a dependency that has been held up for some reason. A short, temporary block is a reasonably common occurrence and nothing to get too concerned about, because in most cases, other work can be taken on while the dependency is being taken care of. The important thing to note is that you want clear visibility of all blocked tasks, irrespective of how temporary the block may be. The way I like to track blocked tasks is to simply spin the corresponding sticky-note 45 degrees so that it looks like a diamond and stands out on the task board. This is a clear signal and allows you to immediately jump into detective mode to ensure that the block is removed as quickly as possible.
Understand the Terrain
If you’re like me, you will be stunned when you think back to all of the impediments that occurred throughout a project. It is often only when you reflect on the compiled list of tracked impediments that you can really appreciate the difficult terrain your Scrum troops have had to negotiate.
This impediment list can also prove invaluable if ever you must defend the team should it fall under an uncomfortable spotlight due to incremental delays that have started to impact release dates. I certainly found that if you carefully ConTROL impediments when they decide to rear their ugly heads, these uncomfortable situations will be few and far between.
If you liked this article, you can:
Subscribe to this RSS feed!
Thank you for this very enlightening article. However, I often discover another problem, which is probably a bit in the grey zone. We have a rather small team, as you described above, and team members are often asked to anser support questions etc. So this usually does not exceed 2 hours per day, because it’s answered quickly and is then solved (at least for a while).
But: These issues pop up every now and then, so the team is constantly disturbed. Although maybe spending their 6 hours per day they are much less productive than they could be. And you can’t even measure this (at least I can’t).
We now introduced a core development time from 9 a.m. to 3 p.m., with email and messenger turned off or ignored, and people asking for support are dismissed. That sounds rude, and of course it’s done in a friendly way 🙂
This helped somehow to solve that problem, but still, impediments don’t only cost time, they can also cost efficiency, and compared to time efficiency is hard to measure.
No problem at all Ruediger and I appreciated the feedback. Your solution sounds spot on except that I know how hard it is to maintain discipline with this approach. Are you finding that the rest of the organization is complying? If so, I think you have done really well. My only suggestion would be to have two one hour periods (late morning and late afternoon) rather than just at the end of the day to offer a bit more flexibility.
Impediment reports are awesome. I’ve recently implemented SCRUM with a small team whose product is fairly high profile in the company I work for – as a result there are people attacking me left right and center with feature requests – each request is, of course, far more important than the last. Most requests I simply throw in the backlog, smile and invite them to the next backlog grooming session with the Product Owner. But some have come from ‘the man upstairs’ and this is where the impediment report started shining.
But not at first. My guys were already a little sceptical about SCRUM and when these impediments started flowing in (and there was a good weeks worth of them) they lost faith in SCRUM because the sprint wasn’t going as planned – it was going out the window. I have to admit it was making me question my faith as well. Nonetheless I presented my impediment report to my manager (also weekly) who said we just had to grin and bear it.
Two weeks later he had people asking him why “such and such” wasn’t done as promised – he simply handed them my report, showed them an itemised list of the impediments and what they cost and washed his hands. So next week I’m being sent to ‘the man upstairs’ to explain SCRUM to them.
In short the impediment report got their attention, hopefully open their minds and got me one step closer to a smoother sprint!
Great work Nick! Sounds like you are doing the hard yards but making some headway. That report has also saved me a great deal of pain and suffering. Thanks for sharing your experience.
“@ScrumAlliance: How do you deal with impediments? Here’s what @scrumshortcut does. http://t.co/u67DBmy9 #yam
[…] “impediment” and a “block” in Ilan Goldstein view.Read the full blog post http://www.scrumshortcuts.com/blog/planning-metrics/implicating-impediments/Related Content:No Related ContentComments:Add your comment below, or trackback from your own site. […]