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.


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.


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.


Learn the power of silence

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

Persist Claims Transformation in a cookie with MVC and OWIN

Claims transformation (or claims augmentation as it’s sometimes called) in an MVC claims based application is “easy”. All you need is a simple piece of code:

Principal.Identity.AddClaim(new Claim(ClaimType, "ClaimValue"));

Unfortunately, where you add that code isn’t.

## Options

I found a number of options that worked, but didn’t behave in the way I needed.

Option 1 – use a custom [ClaimsAuthenticationManager][1] as detailed on MSDN.

Option 2 – add the above code into the [Application_PostAuthenticateRequest][2] method of Global.asax

Option 3 – if you’re using Owin, to create some [Katana Middleware][3]

## Problem

The problem with all these solutions is the number of times the transformation takes place, i.e. how often that code is executed.

Why would you care about the number of times it’s called? In all the examples I found, you wouldn’t, as “magic strings” are being added to the claims, and therefore it’s really fast. In my case, and I’d imagine most real world cases, you’re likely to be making an IO bound call to a database or web service to lookup the extra claim. You _really_ don’t want to be doing that every _single_ page hit.

## Solution

I eventually hit upon the solution with the thanks to a StackOverflow post which [hinted at using the OnResponseSignIn of the CookieAuthenticationProvider][4]

Provider = new CookieAuthenticationProvider()
    OnResponseSignIn = async context =>
         // Apply Claims Transformation here

The OnResponseSignIn is the last chance you have to transform the ClaimsIdentity before it is serialized into a cookie during sign in. The code is only executed once, so no need to be concerned about performance when making a call to a lookup service.

 [1]: https://msdn.microsoft.com/en-us/library/system.security.claims.claimsauthenticationmanager(v=vs.110).aspx
 [2]: http://dotnetcodr.com/2013/02/25/claims-based-authentication-in-mvc4-with-net4-5-c-part-1-claims-transformation/
 [3]: http://leastprivilege.com/2013/09/18/claims-transformation-middleware-for-katana/
 [4]: https://msdn.microsoft.com/en-us/library/microsoft.owin.security.cookies.cookieauthenticationprovider.onresponsesignin(v=vs.113).aspx