As a Scrum Master, impediment removal is not only an essential part of your job, but it’s probably one of the biggest ways to have a positive impact on team velocity. Even a highly motivated, highly skilled team are going to struggle if half of their equipment is broke!
What I didn’t realise when I first started out was that there are many different types of impediment. I guess as I have a technical background I automatically focussed on things like “slow pcs”, “technology X isn’t great”, “my monitor is too small” and “technical debt”, but as I work with more teams and different customers I’m beginning to realise the subtle issues are much more common.
Types of Impediment
In order of smallest scope, all the way out to the whole organisation, here’s a list of some of the types of impediments you might encounter. Another post will detail who I think should own the impediment and try to resolve it.
Technical Impediment
I find these are the most obvious to spot as the team member suffering tends to point it out. I’m thinking “my mouse is broke” or “my PC won’t boot” types of things.
Team Member Impediments
Ignoring personal issues, these could be an individual team members lack of experience with a technology the team uses. Identifying these types of issue can sometimes be hard as developers don’t like admitting they don’t know something.
Technology Impediment
Similar to team member impediments, but this time something affecting the whole team. It could also be lack of experience, or it could be something more technical. For example, upgrading from Entity Framework 5 to 6 makes unit testing a lot easier, but if you can’t for whatever reason, this would be a technical impediment.
Process Impediment
You still have processes right? “Individuals and interactions over processes and tools” doesn’t mean no processes. So this type of impediment could be something like “the code review process is poorly defined and we’re not getting value for money”.
I find these quite easy to identify as the more experienced members of teams seem to be very vocal if something is lacking. If you aren’t that lucky, try and encourage a more open dialog between the you and the team. If that fails, hold a “processes focussed” retrospective.
Team Impediment
Team impediments can be very hard to see quickly and unfortunately tend to have the highest negative impact. The issue is very likely to have a negative effect on morale let alone velocity. I most often see one team member dominating your planning sessions, talking over everyone and worse, criticising other team members ideas and work.
I’m classing this as a team impediment instead of individual as the whole team is affected and it could be up to the whole team to address it. Unfortunately the most common outcome is often the “bad apple” being removed from the team.
Organisational
These can be easy to identify, but very hard to resolve as they’re often outside the control of the team. For example, I have a person on my team who is constantly being asked by other managers to help out with other work. As a result, they are never able to properly focus on the work for my project.
Summary
That isn’t an exhaustive list, but will hopefully get you thinking about the types of issues a Scrum Master has to deal with. In an upcoming post I’ll go through the same list again stating who I think should own the impediment and therefore get it removed. It’s not always the Scrum Masters job!
Comments Section