What is an Impediment?
Definition
/ɪmˈpɛdɪm(ə)nt/noun hindrance or obstruction in doing something.
“a serious impediment to scientific progress”
Synonyme: hindrance, obstruction, obstacle, barrier, bar, handicap, block, check, curb, brake, restraint, restriction, limitation, encumbrance, deterrent
What we understand as Impediment [1]
“An impediment in Scrum is a factor that blocks the Development Team in its creation of a valuable piece of software in a Sprint, or that restricts the team in achieving its intrinsic level of progress.” [Scrum a Pocket Guide]
“Problems that go beyond the self-organization of the Development Team.”
“An event that impedes any of the developers from working to their anticipated sprint.” [Scrum Shortcuts]
Some examples
Some tangible examples that show real world issues worth solving from [1] and enhanced with own experiences:
- Illness of team members
- Unforeseen and undesired changes in team composition
- Issues with the tooling of the Development Team
- Scarcity of skills
- Burndown chart is not “burning” down (“no progress”)
- To much work has been started in parallel (WIP-Limit is not fulfilled)
- Lots of technical debt
- Lots of defects
- Problems with suppliers
- Unavailability of the Product Owner
- Undesired pressure from management
- Conflict between team members
- Lots of unimportant meetings the Development Team has to attend
- Restrictions to the team environment
- An indecisive Product Owner
- Lack of prioritization of Backlog
- Lack of a clear Roadmap
The Scrum Master as Impediment Remover
“A Scrum Master should create an environment where the Development Team feels safe to raise impediments. Respecting the self-organizing capabilities of the team, the Scrum Master should encourage the team in trying to solve their own problems. Or even better, preventing something to become an impediment at all.” [1]
- “A good Scrum Master creates an environment where raising impediments can occur. A great Scrum Master creates an environment where creativity can occur.” [Scrum Mastery]
- “A good Scrum Master will push for permission to remove impediments to team productivity. A great Scrum Master will be prepared to ask for forgiveness.”
[1]
Is there nobody taking care of Impediments, reaching the sprint goal can get in danger and Development Team motivation will drop (besides not reaching project goals).
As a Scrum Master you are not alone responsible for solving each and every impediment. You should make sure that at least someone is taking responsibility for solving impediements, this can be a team member as well as someone from oustide of the team.
Besides that, a Scrum Master provides many more Services, read more about them here.
Debug the Sprint Algorithm
Breakpoints for Inspection
- Daily Standups
- Retrospectives
- Sprint Reviews
- Quality Gates: DoD, DoR
Install Exception Handling
Allow raising problems that impede the team in making progress. Catch them, qualify them, add them to the Impediment Backlog and make sure that they get solved.
Impediments in an agile world
Types of Impediments
Internal or External
- Internal Impediments
- Scrum Master or someone of the team can fix the impediment. Team is capable of solving it fully within their team.
- External Impediments
- Scrum Master needs to find someone from outside the team to solve them. Like providing more hardware ressources for the test environments.
Criticality
- Blocker
- requires immediate reaction and quick solutions
- Improvement
- should be added to the Impediment Backlog and prioritized. Nothing seriously will happen if they get not fixed immediately, but an overall improvement to the Development Teams productivity is expected once it get solved. #kaizen
Size
Some impediments may be small and quickly solveable.
Some impediments may take a while till they get finally solved (e.g. fighting for an organisational change that has consequences not just for one team, but the whole organisation). [2]
Identify, qualify and debug Impediments
Identify
Most of the time Impediments are encountered/identified during Daily Standups. But as mentioned above, it should not stay the only possible point in the Sprint where problems can be raised. An environment needs to be established that allows raising them at any time instead. With that said it’s obvious, that not just the Scrum Master is responsible for identifiying but, but rather the whole team (altough an expereinced and great Scrum Master will have already kind of a seventh sense for recognizing them or even already predicting and preventing them before they occur).
Qualify
Follow this process for qualifying impediments:
Debug
How to figure out what an impediment is and what the REAL problem is?
Applying one of these strategies can be helpful to understand impediments:
- 5-Whys
- “5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. ”
- A3 Problem Solving
- Wunderfrage
- Creativity technique to identify the demanded change
Management of Impediments
Tactics for Removing
Removing impediments is a challenge. But by applying the right approach and mindset, it’s surely doable. [1]
- Create right environment for raising impediments: Don’t wait until the Daily Scrum! Sure, one of the suggested Daily Scrum questions is “Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?” But that doesn’t mean the Development Team can only discuss impediments during the Daily Scrum.
- Use a Sprint Goal. A clear Sprint Goal is an useful instrument to determine if something is truly an impediment. If something prevents the team from achieving the Sprint Goal, than it’s surely an impediment.
- Improve transparency by using an ‘Impediment Board’. This can be a simple flip-over where the impediments are visualized. Add some swimming lanes like ‘to do, in progress, done’ and the status is transparent for everyone. Of course you can also add the impediments to the existing Scrum board. Visualizing the status and increasing the transparency hereby is the most important. ==> see Impediment Backlog->Tools below.
- Understand the organization. A Scrum Master should understand the organizations culture. He should understand how things get done in the organization. By choosing the right approach, difficult impediments can be tackled easier. Sometimes the Scrum Master also behaves as an Organisation Developer, helping to transform into a more productive environment.
- Be brave and creative in removing impediments. Be prepared to ask for forgiveness afterwards when you need to take bold decisions to ensure the Development Teams productivity.
- Collaborate with the Product Owner. Quite often impediments will be related to product management and collaboration with stakeholders and suppliers. The Product Owner is a key player on this area. Therefore ensure a healthy relationship with the Product Owner.
- Stop spending time and effort in solving the wrong problem. With impediments, Scrum Masters need to resist the desire to fix it, solve it and offer solutions. They should focus on the real problem, not the first problem. Ask questions to understand the situation. Check if it’s really an impediment or a learning opportunity for the Development Team. ==> Also see “Identify Impediments” above
Impediment Backlog
The impediment backlog is one of the most important tools of a Scrum Master: it contains the work that needs to be done.
Criteria for a good Impediment backlogs
Good criterias have been already defined by [2], [3]. In a slightly enhanced version you can find the below:
- Visible & Transparency
- “We take care of these issues”
- Only public accessible backlogs will unleash the full potential of also getting solved quickly. There is no reason to hide them.
- Commitment
- “These problems are known and you can see our progress on each of them. We take care of them till they are solved to our satisfication.”
- Appreciation
- “You are having a problem, we are listening to you and we take care.”
- Accessible
- Working with remote teams? Then make sure you don’t rely on physical impediment backlogs as not every will have access to it. See Tools below of how to handle that.
- Trackable
- It’s clearly outlined in which state each impediment item is at any time. Demonstrate progress in solving issues, this keeps the team trusting the Scrum Master that he is capable of turning the current situation to something better.
- Well managed and prioritized
- Are we really working on the most important impediments? Or just the nice-to-have “beautify-the-office” tasks? Make sure to get feedback from the team by letting them vote what’s mostly blocking them at the moment if the backlog is too crowded. Like a PO, the “product” of the Scrum Master is a performing motiviated Development Team, do all you can to achieve that.
- Editable/Contributeable
- Read only impediment backlog? Noooo! Let the team contribute, let them provide ideas, solutions, or even let them raise and add new impediments.
- Never empty
- You gonna tell me that you have removed all impediments? Really, you must be a genius! There is nobody who can ever claim, that there is not a single thing that still can be improved. It is more a sign that the Scrum Master has not yet the full capacity of recognizing what still can be improved.
- Shareable
- Working in large scale distributed scrum project with many scrum teams? Then it is necessary that Scrum Master can share their backlogs, in order to avoid that everyone is trying to solve the same problem. By doing that, and also by installing Scrum of Scrum Meetings, synergy effects can be easily unleashed. Decide which Scrum Master is taking lead of common impediments, but provide him with support – it will kick changes in enterprise organisations quicker if a larger group is jailing about the same issue.
Fullfill these requirements by applying the right tools.
Tools for Impediment Backlog Management
There are some tools that I personally feel good enough to support the role of an Impediment Backlog by fullfilling all above mentioned criterias.
There are some who may prefere physical taskboards, whereas I always prefer having a digital one as you can more easily add new tasks/notes to the Impediments while on the way.
Trello
Template Board:
- advantages:
- Supports remote/distributed team settings
- Free
- Easy to use
- Easy to adapt
- Easy to share (once you know how to do it)
- Mobile App available
- Offers loads of Power-Ups like Burndown Charts, Repeating Tasks, Checklists and Templates
- disadvantages:
- haring requires adding team members one by one
- Potentially an additional tool that is not integrated in the daily used Sprint Taskboard
- Not physically, only virtual 😉
Google Spreadsheet
- Download free Impediment Backlog Template
- advantages:
- Supports remote/distributed team settings
- Free
- Easy to use
- Easy to adapt
- Easy to share (even for large customer groups)
- Mobile App available
- disadvantages:
- Potentially an additional tool that is not integrated in the daily used Sprint Taskboard
- Not physically, only virtual 😉
Issue Tracker of your choice (Jira, Assana, …)
- advantages:
- Supports remote/distributed team settings
- Fully integrated in your day-to-day sprint taskboard tool-suite
- disadvantages:
- Potentially an additional tool that is not integrated in the daily used Sprint Taskboard
- Not physically, only virtual 😉
Wikis
- advantages:
- Supports remote/distributed team settings
- most probably already available as every state-of-the-art project is using Wikis like Confluence for maintaining their documentation anyways
- All stakeholders can get easily access
- disadvantages:
- not a real ticket-system
Physical Taskboard
- advantages:
- Supports remote/distributed team settings
- Fully integrated in your day-to-day sprint taskboard tool-suite
- disadvantages:
- Does not support remote teams
- Hard to maintain, always requires physical updates
- You have to explain the stakeholders where they can find the taskboard, will probably lack of acceptance
Monitoring of Impediments
Once you have created an environment which allows raising of impediments and your impediment backlog is created and filled, you have to keep track of the progress of all your impediments.
The best approach is: apply same agile methodology (or you can also call it the PDCA-cycle – Plan-Do-Check-Act):
- Plan: Do a planning and priorisation
- Do: plan sprint commitment
- plan impediments you want to work on in the next iteration (would be nicely fit if using the same iteration-cycle of your team, so you can present results on impediment backlog at the end of the sprint in the review or retro again). work on them iteration by iteration
- Check: show progress: sprint review/retro
- Act: get new backlog items and new priorisiation input from retro, start again with 1.
Advanced Impediment Management
more to come soon about the following topics:
Impact & Risk Analysis
It is crucial to understand the potential impact/damage an Impediment can cause for the Development Team or the whole organisation. There are a few easy ways how you can do that.
“If you don’t actively attack the risks, the risks will actively attack you.” [4]
Experience shows that handling risks proactively, as is the case with risk management, is less expensive than correcting problems in the aftermath. [5] |
Risk management process
- Identify Risks (Risk Assesment)
- Evalutate Risks (Risk Analysis)
- Define risk avoidance and risk-mitigation measures (Risk Managmenet Planning)
- Define risk reporting system (Risk Monitoring)
- Implement risk avoidance and risk mitigation actions (Risk control)
- high-priority risks (A quadrant) are those which are rated as “high” for one parameter and at least “medium” for the other;
- low-priority risks (C quadrant) are those rated as “low” for one parameter and at the most “medium” for the other; and
- the other risks are assigned medium priority (B quadrant).
What is the role of management?
Senior management support and commitment is critical to the success of any risk management initiative. A formal risk management process requires corporate acceptance of risk as a major consideration for software management. Senior management must support project risk management activities by:
- 1) providing adequate personnel, budget, schedules, and other resources (e.g., tools and equipment);
- (2) ensuring project management receives the required training in identifying, managing, and communicating software risks; and (3) ensuring project personnel receive the required training in conducting risk management tasks. Senior management reviews risk management activities on a periodic and event-driven basis.
Methods for Planning Control Measures
- risk acceptance
- no action is taken to counter the risk, the impacts are accepted. This strategy can be opted for if the impacts are minor or if the effort required to implement the measures exceeds the impacts of the risk events
- risk prevention
- attempts are made to prevent the risk event from occurring at all. This strategy is chosen when the impacts are serious;
- anti-risk measures
- targeted redundancies (e.g. duplicate processors and disks in tandem systems);
- risk mitigation:
- this strategy reduces the probability of the risk event occurring or the degree of the impacts;
- risk research:
- additional information is obtained. This strategy is opted for if the individual risk elements are not sufficiently transparent;
- risk reserves:
- reserves are included in the project budget or time frame. This strategy is chosen when there is great uncertainty in the project;
- risk transfer:
- the risk is passed on to other persons, groups or organizations. This strategy is used when others control the risk and the measures to be taken.”
“Risk Management is a practice with processes, methods, and tools for managing risks in a project. It provides a disciplined environment for proactive decision making to
- assess continuously what could go wrong (risks)
- determine which risks are important to deal with
- implement strategies to deal with those risks
There will be a cultural shift from “fire-fighting” and “crisis management” to proactive decision making that avoids problems before they arise. Anticipating what might go wrong will become a part of everyday business, and the management of risks will be as integral to program.
Download free Risk-Management Template
Hypothesis Validation
For Impediments that classify themself as an Improvement, the Hypothesis Validation approach is a good strategy to do so:
Download free Hypothesis Validation Template
Where to go from here
Key take-aways:
- Respect the self-organizing capabilities of the Development Team
- Create an environment that allows pointing out impediments
- Take over responsibility, teach, coach and give back responsibility to team. The Scrum Master should not be the only one working on Impediments.
- “Considering every minor issue an impediment that needs to be resolved by the Scrum Master, doesn’t help the Development Team grow as a whole. It’s about continuously finding the right balance between preventing or fighting a fire. “[1]
Sources
- [1] Scrum.org, https://www.scrum.org/resources/blog/scrum-master-impediment-remover, page viewed at 19.2.2019
- [2] Claudia Meindl, https://alphanodes.com/de/scrum-impediments-kurz-knapp-erklaert#, page viewed at 19.2.2019
- [3] Boris Gloger, https://www.borisgloger.com/blog/2018/03/16/das-impediment-board-aus-sicht-des-managers/, page viewed at 20.2.2019
- 4] http://www.itq.ch/pdf/RM__ITProjekteV211.pdf
- [5] http://www.chandleraz.gov/Content/PM201RiskManagementGDE.pdf