Probably the most known purpose (task) of a Scrum Master is to remove impediments. If that is reassuring: it’s even described in the Scrum Guide. A Scrum Master is indeed ‘officially’ expected to remove impediments to development and to the Development Team’s progress.
Unfortunately, this is sometimes interpreted as the Scrum Master having to be an ‘impediment hunter‘. That suggests that a Scrum Master should proactively search for impediments in order to track them down and kill them. There is a danger in this wording, besides the very negative feel to it. I particularly wonder how this aligns with the self-organization of teams and transparency? Self-organization is essential in Scrum and it’s to be promoted, served, coached, taught and mentored by that same Scrum Master. Transparency is required to know about reality, inspect it, learn from it and make proper adaptations.
An impediment is an “obstruction; hindrance; obstacle”. And Scrum is a framework that helps teams in finding better ways to create working software in 30 days, or less, and handle the complexity attached to that. An impediment in Scrum is therefore anything that blocks the (development) team in its creation of a valuable piece of software in a Sprint, or restricts the team in achieving its intrinsic progress.
Where to find an impediment?
We can expect a team to raise an impediment, any annoying problem that is truly blocking them. Actively looking for (‘hunting’) and removing impediments is solving problems that are not a problem yet. It assumes that a Scrum Master, as 1 single person, knows more -or pretends to know more- than the united brains of a complete team of up to 10 people; a team that daily makes hard choices by disciplined collaboration.
Solving a problem before it’s a problem points at a lack of belief in the self-organizing capability of a team. Solving a problem before it’s a problem prevents learning and improving because it obfuscates transparency to the team. Solving a problem before it’s a problem is mostly a waste of time and energy because the team will probably handle it by itself anyhow, without the Scrum Master, preventing it from turning into something that truly blocks them. They probably even solve more problems than the Scrum Master knows or can imagine.
It’s simple, an impediment is not an impediment if it hasn’t been raised by the team. Impediments cannot be anticipated. And if there undeniably is an impediment (not an anticipated one and not an issue that the team is already handling) and it is not being raised, the question of the safety of the environment arises. What is preventing the team from raising the impediment?
Not raising an impediment does block the team. What’s then the real problem for the Scrum Master to solve?
What does an impediment look like?
Issues only become impediments if they cannot be tackled within the self-organizing ecosystem. The concept of ‘impediments’ is not a replacement of the traditional escalation procedures. Traditionally people are told to escalate whatever bothers them to a person external to their work to solve it for them. Easy and convenient. But is it also helping?
Scrum delivers great results because it thrives on self-organization, accountability and skills; it appeals to those elements. Scrum restores the respect for people and the understanding of software development as complex and creative work. By definition, in Scrum an issue only becomes an impediment if it can’t be unblocked through the authorizations of the (development) team.
Let’s illustrate this with the example of a team conflict, a conflict between team members.
A team might have problems in resolving a conflict and call the conflict an impediment, expecting the Scrum Master to remove it for them. They expect the Scrum Master to solve the conflict. However, working as a team inevitably includes getting to know each other, finding ways of building software together, exploring different ways to collaborate, outgrowing the desire for personal heroism, and improving through constructive disagreement. Conflicts are a part of working with people, part of becoming a self-organizing team, part of aiming at high performance.
Once again we should raise the question what the real problem for the Scrum Master is to solve? Is it the Scrum Master’s role to solve the conflict? Or would that be an undesired intervention in the self-organizing ecosystem, undermining future honesty, learning and self-improvement? How can the Scrum Master facilitate self-organization? Is it by offering teams an excuse, an external decision to hide behind? Consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to do this.
Not dealing with an issue does block the team. What’s then the real problem for the Scrum Master to solve?
Gelukkig genoeg hadden we ons goed voorbereid op het vlak van toegang en (vooral) de verboden voor kinderen met een beperking. Spontaan en probleemloos werd ons een lijst van het verbodene overhandigd (‘Gids voor personen met een handicap en hun begeleiders’), zoals we die op de website al hadden gevonden. Maar op de website stond ook de mogelijkheid om wel toegang te krijgen mits begeleiding en een schriftelijk akkoord (zie ‘Bijlage‘ aan voornoemde gids). En ik was wel verrast dat ik daar heel expliciet naar moest informeren, om dat document dan pas te krijgen.
Maar kom, het bezoek was erg geslaagd. De nieuwe figuurtjes, zoals Maya, Wickie, Dobus en Bobo, geven toch een opfrissing aan het park. Op zo’n 2e januari is het ook niet echt vreselijk druk en dat maakt het aangenamer, vooral door de afwezigheid van wachtrijen. Verder vonden we het nieuwe indoorpark Mayaland erg leuk. Daar hebben we op verschillende manieren door de lucht gevlogen, in het ballenbad en de speeltuin gespeeld en van de maxi glijbaan gegleden. Het was ook aangenaam om er ‘s avonds, net voor het ‘verplicht’ afsluitende bezoek aan de shop en de tocht huiswaarts, nog even lekker terug op temperatuur te komen. Trouwens, Nienke heeft een pracht van een Kwebbel-muts gekregen!
