Developers identify and report any impediments to the Scrum Master

I usually define “impediment” as an obstacle or barrier that significantly hinders or prevents the work of the Developers from being carried out, blocking one or more Sprint Backlog items in a way that threatens the Sprint Goal. According to this definition, resolving an impediment is not within the reach of the Developers – either it is outside their work context, or it will take too much time. In this way we differentiate impediments from day-to-day problems, which the Developers themselves can solve without threatening the Sprint Goal.

The Developers should seek to protect themselves and prevent impediments in their work. If they encounter an impediment that cannot be avoided, they immediately inform the Scrum Master, who then takes the necessary actions to remove it as quickly as possible. The Developers don’t wait until the next Daily Scrum meeting to communicate any impediments to the Scrum Master, but actively do so during their work.

Signaling of impediments

In addition to verbal communication, a good practice that can be used by the Developers is to visually flag the impediment on the task board that represents the Sprint Backlog, next to the affected item or task.

While this flag does not replace the action of immediately reporting the impediment to the Scrum Master, it does help both the Scrum Master and the Developers not to neglect and better deal with the impediment.

A typical example of this type of flag is marking the impeded item or task with a different color, either by pasting another sticky note over the item or task (when the Developers use a physical task board), changing the color of the item or task (in the case of a virtual task board), or using some other type of marking. The following figure shows an example of how we can flag an impediment on a task.

Prevention of impediments

In general, impediments can be evidence of serious problems in an organization’s structure, the quality of its processes or the quality of the products developed. For this reason, it is important that Developers do not consider impediments as a natural and acceptable factor in the process.

Impediments also generate waste by leading to an undue consumption of energy by the Developers. This effort involves identifying the impediment as such, which presupposes an initial effort to resolve it and involves interrupting the work, flagging the impediment to the Scrum Master and context switching resulting from changes to the item in progress. Impediments also increase the amount of work in process, since the Developers will need to initiate new items while the impeded ones are on hold and thus deadlines are extended and the number of the done items at the end of the Sprint is reduced.

Considering these extremely negative effects of impediments, it is good for the Developers to first of all seek to prevent the occurrence of the impediments themselves. To be able to do that, the Developers can use some important resources, such as the examples described below (PIMENTEL, 2009):

• A true commitment the realization of the goals — The lower the engagement and, therefore, the motivation of the Developers regarding the Sprint Goal, the more easily a problem whose resolution is within their reach could be understood as an impediment and accepted as such. In this sense, such a problem may, even if unintentionally, be used as a reason for a delay or even for not carrying out the work.
• Using the iteration dynamics and timebox to their advantage — External requests or initiatives from the Developers themselves that divert the focus of their work from the Sprint Goal can also become impediments. As such, it is important for the Developers to be able to question whether the urgency of an interruption is real, or if it can wait for the next Sprint, in which the necessary work would be properly planned. The Sprint Goal can be seriously threatened, for example, when a request from top management causes the Developers to stop what they are doing to meet it, thus abandoning the original planning. The same problem can occur when the Developers decide to test or deploy new tools to improve their productivity during a Sprint but spend too much time on these unplanned activities. Bear in mind here that if the Sprint Goal loses its meaning, the Sprint will probably be canceled (see Can the Sprint be cancelled?, in the Sprint chapter).
• Preemptive flagging of the Scrum Master — As soon as they identify an impending impediment, the Developers ask the Scrum Master to help them reject this impediment before it even materializes, thus protecting the activities being performed. For example, as soon as they identify a future need that requires the timely involvement of an external person or team that is not easily available, the Developers can immediately request action from the Scrum Master to anticipate the problem and ensure the availability of that person or team.
• Identifying possible dependencies at the time of planning — By identifying at the time of planning (Daily Scrum, Sprint Planning, or release planning) any internal and/or external dependencies that could impact their work during the Sprint, the Developers may be able to find ways to avoid them or anticipate the involvement and actions of actors who could help address them. For example, we do not recommend implementing a feature that depends on a tool or an external person that may only become available during the Sprint.

It is therefore important that the Developers seek to protect themselves and prevent impediments, treating them not only as something that interferes with their regular day-to-day tasks, but as something that can thwart and even compromise their goals.