Who owns impediments?

In a previous post I listed some of the different types of impediment to identify as a scrum master. In this post I’m going to go through the same types and list who I think should own them and some ideas of how to try and remove them.

Types of Impediment

Different Types of Impediment to Identify
Different Types of Impediment to Identify

In the same order of smallest scope, all the way out to the whole organisation.

Technical Impediment

Some organisations I’ve worked with make it the responsibility of the team member to raise support requests to get things like “my monitor is broke” resolved, but I think that’s a mistake. Sorting out issues (or going to PC World to buy parts) is a waste of team members time. The scrum master as “general dogsbody” should be solving this.

In the meantime, is there another machine to use because someone is on holiday, ill or in a meeting? Could they pair with someone? Basically, don’t treat broken equipment as dead time.

Team Member Impediments

Again, ignoring personal issues (they might be a HR problem), these types of impediment fall squarely on the individual.

I’m a strong believer in treating people like adults, so although it may not be their fault they are not familiar with a technology – that’s an organisational issue in resourcing – they now need to become productive.

It’s the Scrum Masters job to help with that in any way they can, say putting them in touch with the company SME or other training resource, but ultimately the individual has to put the work in.

Technology Impediment

I believe the team should prove to themselves that changing the technology is worthwhile. Once they are convinced, getting buy in the from the product owner and stakeholders to complete technical stories and not add business value should be easier.

Using the example from the previous post of upgrading from EF5 to EF6, ask 1 person to come up with a business case detailing the return on investment of performing the upgrade. It’s a balance between how long the upgrade will take, including roll out to production environments vs how much time it will save in the future.

If there’s 2 weeks left on the project, it’s going to take 5 days to upgrade and save 1 day it’s not worth it!

Process Impediment

If you do have a vocal member of the team telling you something is lacking, I would use this opportunity to try and coach them to become solution orientated. I’d task that person to take ownership and come up with a solution but provide lots of assurance that if they’re solution doesn’t work it’s not a problem.

Team Impediment

These types of impediment can be very hard to solve and unfortunately the ownership falls on the scrum master.

If you are unfortunate enough to have a “bad egg” and you’re inexperienced with dealing with these types of issue I recommend you speak to your HR department for advice. If that’s not possible, seek advice from someone who does.

Organisational

The Scrum Master Podcast calls this “the dreaded system”. I imagine they’ve used the word “dreaded” because changing the system you work in can be almost impossible.

Ownership again lives with the Scrum Master, not to solve them, but to try and isolate the team from them. I find a great exercise to help with this is Circles and Soups retrospective.

Summary

Not all impediments are the scrum masters to solve, sometimes it can be really beneficial to pass ownership to a team member.

This obviously isn’t an exhaustive list and I’m not going to claim it’s perfect, so please leave a comment below or catch me on twitter if you have any comments.

Different Types of Impediment to Identify

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

Different Types of Impediment to Identify
Different Types of Impediment to Identify

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!

Scrum Master Tip – Many Voices

This is a quick tip that I struggled with when I started as a Scrum Master and wish someone told me about.

Issue to Avoid

One person talking for the majority of the time during retrospectives, although this applies to all meetings.

Why is it a problem?

One voice is not only boring for the others, but you’re very unlikely to get the engagement required to improve.

You’re also potentially missing out on a great idea that someone else hasn’t been able to say.

Potential Solutions

Try not to stand at the front talking all the time.

Try asking each team member to present their points and reason for choosing, instead of handing you their post-it.

Try asking a different team member to take the retrospective.

If you’re not getting much in the way of contributions, directly ask the quietest member of the team to say their thoughts on a particular topic.

Try to ask open questions so it’s difficult to give 1 word response. “What do you think of X?” is much more likely to get a good response than “Is X a problem?”.

If after all the above, you’re still getting little input, it may be because everyone agrees. Encourage someone on the to play devil’s advocate and disagree.

Finally:

Learn the power of silence

Most people hate sitting in a silent meeting. If you keep quiet, someone else will fill the void.