Hey Scrum Masters,
I wanted to write to you concerning the issue of Impediments and your part in their downfall.
Every project has impediments. There are two types – the known and the unknown. The more known, the more protected you are against slippages and delays in productivity.
Difference between Impediment and Planned delay.
This is all borne out in Sprint Planning. Let’s use the following example.
QA Tester is testing STORY #A
And it will be ready to test by Thursday.
Today is Monday. So their TESTING STORY #A task will sit in Not Started because it was always planned for the sprint to be tested on Thursday.
However, come Thursday, if the code is not ready to be tested then this is an Impediment. It’s only an impediment when something that wasn’t planned or catered for in the Sprint HITS the sprint.
So what should Scrum Masters do regarding Impediments when they hit?
Call them out.
Sprints are short bursts of development – straight line 100 metre dashes with no need for meetings (aside from standups) and are supposed to go without a hitch. You need to be honest and unflinching about impediments and call them out as soon as they are visible. Anything that will affect the smooth running of the sprint is an impediment. Call it out – encourage and support the team on calling out impediments wherever they may occur –
Various impediment types (there are loads more)
- · One of the team is sick
- · An external department has screwed with the testing environment
- · Estimates for one task weren’t accurate enough which caused a knock-on delay with another task.
- · The Leadership team turn up and want everyone at a cake ceremony for half of the day…
- · A broken keyboard for one of the developers
- · Etc etc
The most important thing to remember when it comes to calling out impediments is that they are not BLACK MARKS seen as negatively scoring the team’s performance. Think of them more as “RED ALERTS telling you that outside invaders are trying to bomb your starship”. [Work with me on the analogy]
Don’t wait for the Red Alerts to sound; go OUT THERE and actively look for Impediments before they become impediments.
So you’ve called them out – now work with the team to remove them.
Your job as Scrum Master is to try and do everything to assist with removing this blockage. When an Impediment is raised you should actively talk about it during standup and ensure sufficient discussion is centred around each impediment. If the team organize themselves in a way to handle impediments then “GREAT” but ensure that their handling doesn’t impact any other higher priority work during the sprint, else you are “robbing Peter to feed Paul”.
Take the examples above – some you can remove some you can’t…This is my reaction to each of these…
· One of the team is sick – OK you can’t cure them, but does anyone have any time in the sprint to pick up the slack? Has the line manager received an estimate for how long the ill person is expected to be out of the office?
· An external department has screwed with the testing environment – does this happen often? If it does then factor it into your sprint planning and don’t rely on it as part of your sprint commitment. If it’s unexpected, then Call it Out and proceed to a discussion concerning reducing the scope of your Sprint. I’d be extra diligent and talk to the external departments involved before the next sprint and remind them of my reliance on the environment and the consequences to our progress if delays occur. I’d also doubly ensure that I’ve managed our stakeholder’s expectations.
Meanwhile, if this keeps happening you should be surfacing the impediment up the chain to someone important enough to do something about it; a key part in persuading that person would be to show them the amount of work descoped each sprint as a result.
· Estimates for one task weren’t accurate enough which caused a knock-on delay with another task. – Discuss this at retrospective and look to use estimation accuracy as a metric to gauge estimates in future sprints. Also, if a delay has occurred to another task you should be questioning whether lower priority tasks should be descoped from the sprint.
· The Leadership team turn up and want everyone at a cake ceremony for half of the day… Encourage you team to attend and enjoy and descope accordingly….but don’t shy away from communicating the reasons why certain User Stories were descoped. If you knew they were arriving then factor the ceremony into the sprint and reduce the number of manpower time available to reflect the time required for the ceremony.
· A broken keyboard for one of the developers… Try and secure a replacement right away from IT. Failing that, look around the office for a keyboard that isn’t being used (leave a post-it note with an IOU). Failing that, go out and buy one and expense it.
· Etc etc – The above examples serve to highlight that impediments come in all shapes and sizes and there are no rules when it comes to removing them.
So these impediments have caused a delay to our sprint? Now what? C’mon!! Descope Descope Descope. Remove all of the lower priority items from a sprint until you are relatively certain that the remainder of the tasks can be completed within the sprint deadline. It’s at this stage that Agile discipline is important. Don’t work around impediments by working longer hours or cutting corners in quality to finish everything on time. Remember the GOLDEN RULE: Agile doesn’t solve problems, it only surfaces them… Working around problems doesn’t remove problems.
Think of reforecasting like a GPS / Sat Nav guide in your car: As soon as you make a wrong turn or an unexpected turn, the guide reforecasts the ETA accordingly. Considering the end point of the sprint will always be fixed, and we don’t want a reduction in quality, then the only thing changeable is scope.
But most importantly…..Learn from all of these impediments. Utilize the retrospective meeting to help the team evolve and learn from all of the stoppages and try and agree some practices that will mitigate against repeat impediments for next time. We never ask for perfect in Scrum, we just ask that you continually improve iteration after iteration.
Thanks for reading, and don’t forget …Impediments aren’t just for Scrum Masters to solve. Everyone can join the fight.
