What are Impediments, how are they visualised and which tips exist for eliminating them?
An Impediment is a handicap – this is how the dictionary explains it. Or an obstacle, an impairment, or an aggravation. In Scrum and thus in agile project management and software development, an Impediment is understood as a disruption that occurs during work and restricts teams or individual team members in the execution of tasks. This disruption is a factor that can jeopardize the achievement of sprint goals. Scrum defines the documentation and removal of Impediments as the task of the Scrum Master, unless the identified obstacles can be removed by the development team itself.
Scrum Master and Impediments
The Scrum Master is responsible for the adherence to the Scrum process and its implementation in the company. He moderates events, detects and removes obstacles, and protects the team from unauthorized intervention during development. It is not his primary task to identify problems – even if this is claimed from time to time. It is his job to document and eliminate Impediments. If necessary, he also involves the company management in this process.
Since the Scrum Master tries to support the development team on the way of self-organisation, it is important to clarify some points clearly:
- Is it an Impediment or could the team remove the obstacle itself?
- Is it necessary to remove the Impediment?
- And where is the concrete, the real problem?
In order to communicate Impediments at all, the Scrum Master should encourage the developers to name problems and, if necessary, to eliminate them themselves. Both are only possible if there is mutual trust.
An Impediment Board visualises problems and obstacles that limit a team or individual team members at work. It can also be understood as a representation of the lifecycles of individual obstacles. The advantage of the Impediment Board lies in the simplicity of the visualisation and the access to information. The visualisation usually takes place in a representation with three or four columns. The first column “Identified Problems” is optional, because every further problem could also end up directly in the column “To be solved”. All in all, the columns show the states of the obstacles.
Ideally, all participants should have access to the display, as this makes it easy for them to see which Impediements have been identified and what their processing status is. This successively contributes to the improvement of working conditions and increases transparency. The level of commitment also increases, as it quickly becomes clear that one goal is to eliminate concrete problems. And this also leads to a feeling of mutual appreciation, because problems are taken seriously and eliminated step by step.
The Management of Impediments in Backlogs
There are two ways to manage Impediments: besides the already described Impediment Board you can also manage Impediments in backlogs. In some organisations, both techniques are used in parallel to deal with obstacles. Opinions differ as to whether it makes sense to maintain a separate impediment backlog or whether it is not sufficient to include the obstacles in the general backlog with a corresponding label.
Examples for Impediments
In principle, an Impediment can be anything that hampers a team in the performance of its activities. Examples:
- The Scrum Master is too often in the home office.
- The Product Owner is too rarely available.
- There are sick employees and thus the sprint goal is endangered.
- There are not enough software licenses for parallel use in the team.
- Skills are missing in the team.
- The monitors are too small and the computers are outdated.
- There are delays with suppliers.
- There is a conflict between team members.
- I have a problem with debugging XYZ.
- The user stories are badly written.
Not all of the examples mentioned need to be Impediments, because a problem is only an Impediment if it exceeds the capabilities of the team’s self-organisation. A lack of skills could possibly be an obstacle that a team solves itself over time. It may also be possible to resolve a conflict between team members through a moderated discussion. A slightly different interpretation separates internal and external Impediments. In the common definition there are no internal Impediments, because these can be solved by the team itself. The Scrum Master takes care of the solution of external problems either alone or with the team, in cooperation with the management or with a “third party”.
Challenges with Impediments
There are some challenges when working with Impediments:
- It is important that the problems managed by the Scrum Master do not disappear in a backlog, but are easily accessible for the team at any time. This promotes the discussion and solution of the problems and prevents the suppression or even oblivion.
- Even if you work very well together in a team, there is still room for improvement. It is therefore practically impossible for an Impediment Board to be empty. If necessary, the Scrum Master has to help more with identification or create a more open climate for communication.
- If there is no change in the conditions of the problems, the work with Impediments, the work and ability of the Scrum Master and the standing of the team as a whole will be questioned. This should be avoided at all costs.
- If the obstacles add up without others being removed, not only the sprint goal but possibly the whole project is at risk. This must lead to an escalation, to prioritisation of the problems and, if necessary, to support by an additional force from “outside”.
- The Scrum Master is not solely responsible for eliminating the problems. It should be the interest of the entire organisation – if necessary after discussion – to remove all obstacles.
Depending on the size of the problem, a quick solution is not always easy. Also in such cases the progress should be documented and communicated openly with the team and the management.
Impediments on the Taskboard
There are organisations that mark Impediments directly on the taskboard, either by small markers like dots on a task or by a separate area next to the tasks. “The more obstacles are documented during the sprint, the more the achievement is endangered” – this could be one interpretation. In terms of content, however, such an interpretation is imprecise, especially since the risk of missing the sprint goal cannot be deduced directly from the number of Impediments. It is therefore advisable to use an Impediment Board, possibly even with an enrichment of additional information such as hints for solving the problems, possible key figures and priorities, contact persons for solutions or time windows. There are few limits to creativity here.
Tips and Tricks for Impediments
Dealing with Impediments is not always easy. There are a number of tips and tricks that can help to document and remove the obstacles:
- There is no reason to wait for the next Daily Scrum to communicate an urgent problem. If the scanner, air conditioner or computer fails, quick help is needed.
- Not only at the Daily Scrum, but also when handling Impediments, an orientation towards the sprint goal offers itself. If an obstacle endangers the sprint goal, it must be repaired quickly in any case.
- The documentation of fixed problems conveys a good feeling – the “successes” can easily be visualised even after a sprint, e.g. for an entire release.
- When dealing with problems, trust is very important. Possible conflicts, missing skills or difficulties in the cooperation with the Product Owner or the Scrum Master concern the team. A visualisation via Impediment Board, which is visible for everyone – and thus also for external team members or even customers – could undermine this trust.
- The documentation of the obstacles should be used as input for the Sprint Review and the Sprint Retrospective.
- If necessary, prioritization of problems makes sense. This makes it clear that a blockade, i.e. an obstacle to a single task, can be less important than an Impediment that jeopardises all progress in the Sprint.
- The Product Owner also plays an important role in ensuring that the Scrum Master primarily ensures that problems are eliminated. He is the one who communicates with stakeholders, works with suppliers and communicates with company management. A good cooperation between Scrum Master and Product Owner is therefore very important.
The removal of Impediments is a skill that a Scrum Master can perfect over time. It’s not uncommon for the visualisation of the Impediment Board to vary over time, perhaps additional information will be added to the board, perhaps some other information will disappear. It is important that it is a tool to eliminate problems as quickly and sustainably as possible.
Do you want to improve the processes in your projects through a uniform approach? Do you want to make the project process comprehensible and create added value for your customers? We would be pleased to offer you our knowledge of processes combined with many years of experience. We support you in working with Scrum, coach your employees, establish a meaningful backlog management and help you with software and system modeling.