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

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!

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.

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 as detailed on MSDN.

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

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

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

 
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.

The 4Ls Retrospective and why you would use it

Background

I’ve just started working on a brand new project as a Scrum Master for a team of 7. There’s quite a mixed bag of experience, ranging from scrum masters to complete agile first timers.

For our first retrospective I wanted something simple to explain, but also simple to take part in. The 4Ls technique leapt out at me.

Variation

For me, “lacked” and “longed for” are too similar, so I always make a slight adjustment and use “Liked”, “Learned”, “Longed For” and “Loathed”. Loathed is a strong word, but I find it helps the team highlight things that are slowing them down, whereas “lacked” is things that might speed them up.

I also add a strict rule of “no more than 6 points each” and you “must have one point in each column”. Why did I do this? Two reasons:

  1. It focuses everyone to their most important points to prevent a flood
  2. It forces everyone to think of positive things, “Liked” and “Learned”, that happened during the sprint. Which I find sometimes doesn’t happen.

I find these two rules help me facilitate the meeting as I can control the duration and topics discussed more easily and prevent the retrospective becoming a moaning session.

Why you would use this technique

An awful lot of the internet nowadays seems to be how to do something, but not the why. It’s become a bit of a pet peeve of mine, so I’m going to try and list a few of the reasons as to why you would use this technique:

  1. You’re a new Scrum Master looking for an easy technique to follow that doesn’t need a lot of input
  2. You’re a Scrum Master looking for a technique that doesn’t take too long
  3. You’re a Scrum Master working on a team that is quite negative and want to get some positive points
  4. You’re the Scrum Master of an inexperienced team and you want to ease them into retrospectives
  5. You’re a Scrum Master who wants to freshen up your retrospectives without pushing the boat too far.

Results

I’m really pleased with the results of this technique.

We got plenty of points to talk about and I felt in control of the whole retrospective. All the team members contributed and we ended up with some useful ideas to try for the next sprint.

As always, I’d love to hear of anyone else who has been in a similar situation and used a different technique. Why?

Please leave a comment below or catch me on twitter if you have any questions.

Personal Retrospective

For my own future reference, I like to analyse my own performance.

What Worked Well

  • Restricting the team to 6 points with at least 1 in each column

What Went Ok

  • Giving an example of what I would chose for each column.
  • It was useful to explain the technique, but I’m slightly concerned it put words in peoples mouths. Perhaps next time use examples that are not to do with the topic, for example my feelings on a TV show.

Change Next Time

  • State explicitly that you can’t have a point that straddles a line between two of the Ls

Visual Studio Tip – Named Parameters in Generated Methods

Really quick tip that I found recently while refactoring some old code.

If your using “Generate Method” (Ctrl + .) in Visual Studio, the method you’re generating uses the same names as the local variables for parameter names:

Generate Method without Named Parameters

Generate Method without Named Parameters

I don’t know about you, but I then have to spent more than a zero time tidying it up to be more meaningful. Thankfully named parameters can take care of that for you:

Generate Method without Named Parameters

Generate Method without Named Parameters

Seems to work for constructors and other refactors too.

Maybe it’s common knowledge, but it pleased me, so by putting it here I can remind myself in a couple years weeks time when I forget.

String interpolation in C# 6

This is the eighth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6. (Now Visual Studio 2015 is available, they’re not so “upcoming”).

This is another really nice piece of syntactic sugar that makes the code more readable and less error prone. Very simply, this appears to be designed to overcome some of the shortcomings of String.Format and its related uses.

Basic usage

In the most basic form, rather than specifying {0}, {1} etc throughout your string, simply prefix the string with $ and you can place the expression you want formatted directly in the string:

// before String interpolation
var output = String.Format("Car {0} is {1} year(s) old", myCar.Registration, myCar.Age);

// String interpolation it becomes
var output6 = $"Car {myCar.Registration} is {myCar.Age} year(s) old";

This is not only easier to read, but will make future maintenance easier. You will no longer have to put the right number in between the curly brackets and count the parameters.

Advanced Usage

A really nice thing about string interpolation is that you’re not limited to just variables, you can in put virtually any expression, for example:

Console.WriteLine($"Car {myCar.Registration} is {myCar.Age} year{ (myCar.Age == 1 ? "" : "s")} old");

Summary

All in all, another great tweak to the language which should help the Developer Experience (DX) – something I saw in the ReactEurope conference.

Null-conditional operators in C# 6

This is the seventh part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6. (Now Visual Studio 2015 is available, they’re not so “upcoming”).

I’m going to come straight out and say that this is my favourite new language feature in C# 6. It’s going to get used a lot and will save a lot of typing and make the code a lot more readable. Basically, this is another productivity boost – a common feature of C# 6 – and I’m sure something a lot of us will welcome.

Example Classes

For the examples I’ll be using, I’ve imagined some strange car insurance system where a car can only have 1 accident and each accident needs only 1 part to replace.

public class Car
{
    public string Registration { get; set; }

    public int? Age { get; set; }

    public Accident Accident { get; set; }
}

public class Accident
{
    public string Reason { get; set; }

    public Part ReplacedPart { get; set; }
}

public class Part
{
    public int Price { get; set; }

    public string Name { get; set; }
}

Obviously not realistic, but I’m hoping once you see the example you can see how this feature will work with any code bases you’re familiar with.

Basic Null-Conditional Operator

To prevent NullReferenceExceptions, you will often see code which makes sure something isn’t null, then does access a property

    string result = null;

    if (car != null)
    {
        result = car.Registration.Substring(0, 2);
    }

    return result;
}

The null-conditional operator – ?. – helps make that code much more succinct.

public string FirstTwoCharactersOfRegCSharp6(Car car)
{
    return car?.Registration.Substring(0, 2);
}

The above code is checking that car is not null before accessing the Registration property and will evaluate to null if it is.

Chaining

It doesn’t end there as you’re not limited to one null-conditional operator, so you can wave goodbye to the days of “Christmas Tree” code where you have multiple levels of if-else.

	return car?.Accident?.ReplacedPart?.Name

Like above, if at any point the property is null, the whole expression results in null.

Combined with Null Coalescing operator

Finally, you can combine this with existing features of the language for yet more neat code.

	var replacedPart = car?.Accident?.ReplacedPart?.Name ?? "Name not specified";

Summary

Like I said above, this is probably my favourite feature of C# 6. The code we write should be more elegant to produce, easier to read and therefore hopefully less error prone.

I confess to leaving off too many null pointer checks because I’m in the zone and a.n.other if-else feels like a pain, but now I have no excuse.

Expression-bodied members in C# 6

This is the sixth part of a series of posts I’m making into Upcoming Language Feature Changes in C# 6. (Now Visual Studio 2015 is available, they’re not so “upcoming”).

Back to the syntactic sugar updates this time, but again, I think this will be used a lot once it gets out in the wild.

There’s not a great deal to say as it’s basically lambda expressions in method and property declarations. In the following code, there’s a class called Rectangle that has several properties like xPos, yPos, Width, Height, etc

Method Declarations

The new syntax can be applied to both methods that return values:

// Before C# 6
public Rectangle Translate(int xTranslate, int yTranslate)
{
    return new Rectangle(xPos + xTranslate, yPos + yTranslate);
}

// With C# 6
public Rectangle TranslateNew(int xTranslate, int yTranslate) 
    => new Rectangle(xPos + xTranslate, yPos + yTranslate);

And to those that return void:

// Before C# 6
public void DisplayLocation()
{
    Console.WriteLine("{0}, {1}", xPos, yPos);
}

// With C# 6
public void DisplayLocationNew() => Console.WriteLine("{0}, {1}", xPos, yPos);

To be honest, it’s not a massive change, but should help reduce a lot of 1 line methods to something much more readable.

Property Declarations

You can also use the same lambda syntax

Using the same example, let’s imagine you’ve decided to declare Area as a getter only property:

// Before C# 6
public int Area {
    get { return Width* Height; }
}

// With C# 6
public int AreaNew => Width * Height;

As you can see, you don’t need to use the get keyword as it’s implicit.

Summary

This is another great feature to help increase productivity. Not only will the code you write be easier to read and understand, it will take less typing.

Slight silence due to React and new Visual Studio

A very quick update – not that anyone reads this – but I’ve been up to the eyeballs in React for the last couple of weeks.

It’s very impressive and I’m definitely planning on writing a blog post or two on it, but not in the short term.

I’ve also been more that a little distracted with the new .NET and Visual Studio – http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing-net-framework-4-6.aspx.