Archive for July, 2012

Guidance on Running Retrospectives

July 28, 2012

Following is the five steps we use to run our Retrospectives.
I’ve purposely made these as terse as possible,
so it can be used as a check list as the retrospective progresses.
Below the five steps I’ve added some extra info and tips.

What’s a Retrospective?

  • A Retrospective is a planned event where a team leader
    (or in the world of Scrum, a Scrum Master)
    guides the team through a process of looking inward.
    In the world of Scrum, we hold a Retrospective at the end of every Sprint.
    What’s Scrum?
    I made a post a while back outlining why an organisation aiming to deliver products that had complex elements, would use Scrum.
    Check it out here.
  • Locating impediments and working out what to do in order to remove them.
  • Move the team along the path of…
    Forming -> Storming -> Norming -> Performing.
  • Make the team a more fun place to be for all members.
  • Implement Kaizen.
  • Increases operational efficiencies for the stake holders.
  • Another opportunity to inspect and adapt.

Structure

  1. Set the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

1. Set the stage

 Time expected (time box)
  • Ask everyone in room to speak a word or two about what’s going on / how they’re feeling.
    This encourages everyone to have a voice and speak early.
    If anyone chooses to remain silent, they must remain silent for duration of Retrospective.
  • Request for amendments to our working agreements?
    These belong to the team.
    They are the teams responsibility.
    Social contract (> 10 points is too many).
    Check whether the Definition of Done (DoD) needs any modifications.
  • Establish environment where people can bring up difficult topics and have challenging conversations.
    Confirm (and establish if not already) the goal of this Retrospective.
    Remind team that Social contract applies for retrospective as it does at any other time.
    Teams personal Social contract should not contain abstract statements,
    but working statements and agreements that help the team talk about emotional, tough issues.
  • If someone is doing to much talking, just say “Lets hear from someone else”.
    Some Product Owners can have this tendency.
  • Review Action Points taken from last Retrospective.

2. Gather data

 Time expected (time box)
  • Hard
  • events
  • metrics
  • features or PBI’s completed
  • Soft
  • feelings
    Rather than asking directly about how people felt, you can get the same info in other ways.
    When were you excited to come to work?
    When was coming to work “just a job”?
    When did you dread coming to work?
    What were the high points?
    What were the low points?
    How was it to be in this iteration?
    When where you mad, sad, surprised?

3. Generate insights

 Time expected (time box)
  • Question why, and encourage team to start thinking about what to do differently.
  • Lead team to examine the conditions, interactions, surprises and patterns that contributed to the Sprint outcome.
  • Record all insights on the white board or a wall.
    insights are potential experiments and improvements taken from the gathered data.

4. Decide what to do

 Time expected (time box)
  • Team picks the top 2 – 3 insights.
    These become the action points.
    Make sure each action point is assigned to someone and dated.
    The best way to make sure these happen is to include them in the next Sprints Backlog as PBI’s.

5. Close the Retrospective

 Time expected (time box)
  • Make mention of the Sprint report and that all should read through it at least once to keep the decisions made in their mind.
  • The learning’s belong to the team. Not the CEO and Not the SM.
  • Show appreciation for the hard work everyone did during the Sprint and the Retrospective.
  • Perform Retrospective on Retrospective (a few minutes).
    It pays to inspect and adapt Retrospectives too.
    Or as the military call it, OODA loop.
    Observe -> Orient -> Decide -> Act

That’s basically it.

Additional Retrospective info and tips

The Retrospective is generally the last event in a Scrum Sprint.
The official Scrum Guide has a terse section on the Retrospective.

Time boxing

Scrum values time box’s.
Generally time boxed to 1.5 hours for a 2 week Sprint.
Proportionally shorter / longer for shorter / longer Sprints.
A general guideline for the 5 steps are:

  1. Set the stage 5%
  2. Gather data 30-50%
  3. Generate insights 20-30%
  4. Decide what to do 15-20%
  5. Close the retrospective 10%

Activities

I’m finding it useful building up a collection of activities to use to drive the Retrospectives.
Have an activity pre-defined for each of the five steps, and potentially a fall back activity also.
It pays to spend some time up front before the event,
preparing what you want the stake holders and the Team to get out of it (a goal).
Good activities to use, should include at least the following traits:

  1. Encourage all team members to actively participate.
  2. Help team members to keep discussions focused on the goal.
  3. Assist in producing creative thinking, and looking at things from different angles.

Don’t use the same activities every Retrospective.
If you and / or the Team is getting bored with the current activity, it’ll become less effective.

Breaks

If your running a Retrospective longer than aprx 2 hours,
you should think about factoring in breaks.
Often 10 minutes is all the team will need.
You as the Retrospective leader / Scrum Master, will benefit from a short break.
Especially if your feeling stressed or under tension.
Shake the tension out of your limbs and get the blood moving to the brain again.
Take a few good breaths.

Closing

I’ve found the book “Agile Retrospectives” by Esther Derby very useful.
Check it out for lots of additional info and ideas.

I wanted to keep the five steps really terse (a check list).
This way you can take them into the Retrospective and glance at them while your leading the event to make sure you and the team are on track.

Comments very welcome.

Tags:, , , , ,
Posted in Agile, Development Methodologies, Scrum | 3 Comments »

A Handful of Singletons in C#

July 14, 2012

Recently I was involved in an interview where I was queried on the Singleton Creational design pattern.
I thought I’d share what I came up with.
In order of preference from most to least used.

Most used:
System.Lazy introduced in .Net 4.0
Sealing the class can help the Just In Time (JIT) compilation to optimise the IL.
Of course you also don’t want your singletons being extended,
but the fact that your constructor is private and default (takes no arguments),
guards against instantiation and sub-classing

Example 1

public sealed class KimsSingleton {

   // System.Lazy guarantees lazyness and thread safety
   private static readonly Lazy<KimsSingleton> _instance = new Lazy<KimsSingleton>(() => new KimsSingleton());

   // private, preventing any other class's from instantiating.
   // Also prevents creating child class's... which would create another instance, thus violating the pattern.
   private KimsSingleton() {
   }

   // static so client code can call Instance property from class.
   public static KimsSingleton Instance {
      get {
         return _instance.Value;
      }
   }
}

.Net guarantees lazy initialisation if the type is not marked with beforefieldinit.
Although it could be more lazy. See example 3 for one way to do this.
Marking the types constructor as static tells the compiler not to mark the type with beforefieldinit in the IL,
thus giving us laziness.
This is also thread safe.
In C#, static constructor will execute only once (per AppDomain),
either on instantiation, or when a static member is referenced for the first time.

Example 2

public sealed class KimsSingleton {
   private static readonly KimsSingleton _instance = new KimsSingleton();

   static KimsSingleton() {
   }

   private KimsSingleton() {
   }

   public static KimsSingleton Instance {
      get {
         return _instance;
      }
   }
}

Example 3

public sealed class KimsSingleton {
   private KimsSingleton() {
   }

   public static KimsSingleton Instance {
      get {
         return Nested._instance;
      }
   }

   private class Nested {
      static Nested() {
      }
      // This gives us more laziness than than example 2,
      // because the only static member that can initialise is the static instance member in Nested.
      internal static readonly KimsSingleton _instance = new KimsSingleton();
   }
}

One more way that I’ve seen used quite a few times that starts to fall apart.
Even the GoF guys do this example.
Head First Design Patterns do it as well (not good!),
although they use the volatile keyword which helps.
Lets look at where it falls apart.
If performance is an issue, stay away from this way.
If you fail to declare your instance member as volatile,
the exact position of the read / write may be changed by the compiler.
I don’t use this method.

Example 4

public sealed class Singleton {
   private volatile static Singleton _instance;
   private static readonly object _lock = new object();

   private Singleton() {
   }

   public static Singleton getInstance() {
      if (_instance == null) {
         // Lock area where instance is created
         lock(_lock) {
            if (_instance == null) {
               _instance = new Singleton();
            }
         }
      }
      return _instance;
   }
}

There are quite a few other ways of implementing the singleton.
Many of which are flawed to some degree.
So I generally stick with the above implementations.

Tags:, ,
Posted in Architecture, C#, Design Patterns | 15 Comments »

Sysinternals Bginfo

July 1, 2012

Following is the process I took to set-up Bginfo on one of the servers I’m responsible for.
Bginfo.exe is a Portable Executable (PE) Sysinternals tool that displays configuration info of pretty well anything you want on the desktop.
Often quite useful for dev and test servers.

Why I set Bginfo up

The main reason for doing this was so we could track:

  1. IIS sites
  2. what database each is using
  3. which domain each is using.

All at a glance.

The idea of this was to help make sure no one deployed software to the wrong place,
and also tell us which databases are being used by what at any time.
With the initial set-up, the IISSites.txt needed to be kept up to date.
In saying that, if you wanted to invest the time,
you could write a script to do this,
and have Bginfo run it and subsequently update the desktop bitmap.

Extra configuration info here.

My Basic Steps

  1. Download the Bginfo Portable Executable (PE).
  2. Create a folder that all applicable users have permissions to.
    I used C:\Documents and Settings\All Users\Desktop\BGInfo
  3. In this folder I put the IISSites.txt that I wanted displayed on the desktop.
  4. In this folder I put the Bginfo.exe PE.Setting up Bginfo
  5. Run the Bginfo.exe PE and click Custom.
    Add identifier IIS Sites and path to the IISSites.txt which is now in the same folder.
    Ok -> File -> Save As…
    I saved the config file as configuration.Bginfo editor
  6. Create a shortcut to the C:\Documents and Settings\All Users\Desktop\BGInfo\Bginfo.exe in C:\Documents and Settings\All Users\Start Menu\Programs\Startup
    This allows Bginfo to run on machine boot.
    In this shortcut we need to put the following:
    Target: “C:\Documents and Settings\All Users\Desktop\BGInfo\Bginfo.exe” “C:\Documents and Settings\All Users\Desktop\BGInfo\configuration.bgi” /timer:0
    Start in: “C:\Documents and Settings\All Users\Desktop\BGInfo”
    Comment: Runs Bginfo the Sysinternals tool that updates the desktop bitmap with the info defined in the configuration file. We’ve also got a scheduled task that runs periodicallyBginfo Shortcut in Startup
  7. You can set the timer to 10 while you are editing the settings, so that the UI actually becomes visible to use.
  8. Also set-up a Windows Scheduled Task to run once a day at 10pm, so that any changes are reflected to the desktop automatically.
    You can refresh the desktop image just by running the C:\Documents and Settings\All Users\Start Menu\Programs\Startup\Bginfo.exe shortcut.
  9. To setup the Scheduled Task, you need to use the same settings as the shortcut in the Startup folder, otherwise it won’t run with the configuration file

By default Bginfo saves it’s image file (BgInfo.bmp) to the current users temp directory.
This seems to provide some buggy behavior in which Bginfo can’t delete an image file before creating a new one. This has the effect of overlaying multiple images.
Enough details to work out the fix found here.
What you need to do is run Bginfo with your configuration file so any changes are saved to it. I just used a shortcut with the configuration switch.
Then Bitmap menu -> Loacation… Change radio button to Other directory: and select the same location that the rest of the Bginfo files are.
This allows Bginfo to delete the image file before re-creating. I used the following:
C:\Documents and Settings\All Users\Desktop\BGInfo\

You can update the info in the C:\Documents and Settings\All Users\Desktop\BGInfo\IISSites.txt at any time.
Once you have and saved it, run the C:\Documents and Settings\All Users\Start Menu\Programs\Startup\Bginfo.exe shortcut.
The shortcut contains the config file switch and the timer switch (currently set to 0, so the UI doesn’t run).

The entire suite of Sysinternals tools.

Most, if not all of these are Portable Executables (PE).
No installation required.
They are a great collection of tools.

You can also run the tools directly from online.

A couple of good pod casts on Sysinternals from Xoke from HPR
Part 1
Part 2

Tags:
Posted in Microsoft | 1 Comment »