random thoughts and discussions on the things that interest me

ScrumMaster Certification

I recently attended a Certified ScrumMaster course in Zurich given by Jeff Sutherland.

While Jeff’s anecdote that he invented Scrum when flying missions as a top gun fighter pilot for the US during the Vietnam war might not be literally true, it might be. Because he did invent Scrum. Well, co-invent it anyway.

As it turned out, the course was a far more valuable experience than I could have imagined it would be. I think in my case that I was able to gain so much from it through being able to relate the work that I’ve been doing in Agile environments over the past five years where I have spent the majority of my time as a Scrum team member in teams that have seen varying degrees of success.

I did not take the course because I want to be a ScrumMaster. I took the course because I wanted to know why when we were practising Scrum projects were liable to fail, team morale was low, there was a disjoint between what we committed to and what we delivered, etc.

And these questions got answered. In fact, all my questions got answered. I understand why these things happened. Now I have some tips on how to go forward. My understanding of Scrum now has a grounding and I can help others to reach that understanding too. But mostly, I learnt that I have much more to learn. But that’s not a bad thing, and in some terms its apt especially as Jeff thinks of Scrum as a martial art.

I suppose the point of this post is that if you’re going to learn about Scrum it would be my recommendation to learn from Jeff. Lets just say “he knows what he’s talking about”.

Tackling Code Reviews using Automation

I’m currently undertaking a QA exercise on outsourced code as it gets delivered. In order to increase the productivity of the review process by reducing the defects raised and number of iterative fix cycles, I have been involved in writing tools that can be used by the external developers for them to check for compliance with specific coding standards and techniques demanded by the business.

The tools I am using for this automation are StyleCop and FxCop, Microsoft’s free code styling and managed code analysis tool. A great number of the standards we have defined are covered by the default rules that ship with these tools but there have been exceptions. For instance, we do not expect any TODO comments in code that has been delivered.

There are several detailed tutorials covering how to write these rules so I’m not going to repeat what’s already out there (links below). (3 parts)

The code for my TODO rule is below. You simply need to call this method from one of the visitor callbacks mentioned in the above posts.

private static void FlagViolationForToDoComment(
    SourceAnalyzer analyzer,
    CsElement element)
    var todoComments = element.ElementTokens
        .Where(e => e.CsTokenType == CsTokenType.SingleLineComment ||
            e.CsTokenType == CsTokenType.MultiLineComment)
        .Where(c => c.Text
            .Substring(0, c.Text.Length >= 10 ? 10 : c.Text.Length)
    if (todoComments.Any())
        foreach (var comment in todoComments)

One of the things to watch for is that if you install StyleCop with the MSBuild plugin that StyleCop may reside in more than one folder with one instance being registered with Visual Studio, and the other with the Explorer shell. In order to update the rules for use with both you will need to copy your rules library into each installation folder; in my case:

C:\Program Files\Microsoft StyleCop
C:\Program Files\MSBuild\Microsoft\StyleCop\v4.4

There’s also a StyleCop contrib project that provides a test-runner allowing unit testing of your StyleCop rules. I can’t recommend this enough – in my mind the only way to write StyleCop rules is to use TDD.