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?
[…] There is a case to be made for this approach of waiting for the team to announce something is blocking them before it becomes an actual impediment. Otherwise, someone (typically a Scrum Master) may presume there is an impediment when one isn’t really there. The danger of this would be when someone doesn’t speak up or when deep-seeded dysfunctions have become the status quo and never mentioned. […]
Sometimes a team is so focused that it cannot see the impediment from a higher abstract level. They would need a facilitator (scrum master) to guide them towards a solution. Also, it happens that a team does not see it has a problem, simply because they things may appear to be OK but in fact they are not (eg code quality, teamwork). In Scrum there is a learning curve, and although this is a responsibility of the development team, the scrum master is the outsider who can monitor progress from a distance. Impediments may not always be obvious or tangible. So, in my opinion,a scrum master can act pro-active in finding impediments
Jan, thanks for sharing this.
You do honestly want to help the team. Why not share your concerns with them? Think about sustainable help. Isn’t that increasing self-organization? What can a Scrum Master do to help the team itself get the understanding you refer to, like by more effectively using the Daily Scrum or the Sprint Retrospective, or engineering standards and the Definition of Done?
Some small remarks: a Scrum Master doesn’t feel like an outsider, but a member of the Scrum Team; with a specific accountability however, i.e. the application of the Scrum framework but not ‘progress’.
[…] Source: http://ullizee.wordpress.com/2012/11/11/impediments-and-where-to-find-them/ […]