bgeek.net

Sometimes change can be very difficult, most peoples instinct is to stay with the status quo and not disrupt the flow, however there are imperative changes that must happen on any software teams and fighting them is like taking a proverbial piss in the wind.

Right now I'm trying to help people around me facilitate change, and one of the key instruments I use is the retrospective.

First lets get to grips with what the goals of a retrospective should be. I once had a mentor (in Cresta) called David Evans, who was awesome at facilitating retrospectives, so the first time I wanted to run one I asked for some help. There are a number of guides and helps that I (and he) uses but one quote from his original feedback really sums up what the goals of such a process are.

Remember that a retrospective is about getting the team to pause and think about what they have done, and what they might be able to do better. These techniques are just prompts for getting that thought process started. Beer helps too.

The first step in getting value from a retrospective is to get everyone involved, if there are members of the team who are disinterested try and find out why, often it can be because of fear of change, it's important to help them realise that without change the product will either a) become impossible to maintain or b) other members of the team will be disenfranchised, as they are stuck inside broken processes that cannot be changed. The last step is to tell them that everyone else will be coming along and if they don't their voice/values won't be heard.

That aside it's still very important to make the retrospective process as casual as possible. This is not a process about blame or individual responsibility rather it's about honesty and ownership. If we want to make the processes as great as possible for everyone, then everyone needs to be part of the process.

So this is the formula that I use for getting a retrospective together.

1) The score:

It's important that certain parts of peoples mood and feeling about progress can be captured in as easy a way as possible, therefor I pick 10 ish agile processes (my favourite are the crystal clear methodologies introduced to me by John Rusk) the methodologies or processes should be definable while still being applicable to all teams (QA, Dev, Design)

at a push you could just list them as

Communication
Focus
Productivity
Quality

but I prefer more fine grained processes

each quality is given a success rating of

Success   Meaning
:-((          We do this very badly, or not at all
:-(           We are not doing this well
:-|           We are adequate at this
:-)           We are quite good at this
:-))          We do this very well

And then an impact rating

Impact  Meaning
0              This has no effect on our success
1              Has some impact on this project
2              Important to this project
3              Critical success factor for this project

The results can then be collated and averaged, and a score can be worked out of success * impact where success runs from -2 to 2

if the result is less than 0 the process isn't working and has an impact, -6 is the worst score

if the result is higher than 0 the process is working and has an impact 6 being the best score

It's then good to focus on the extremes, remembering to remind people of the positives.

2) The Actions:

Finally is the open ended aspect, ask people to come up with at least three positive points to the way current work is happening, three things we need to try and change, and three things that we need to work out how to do.

These points then get brainstormed an written up, these become the action points between retrospectives.

I can't stress how useful it is to get time set aside to do retrospectives, I've seen too many teams keep plodding on without taking time to make sure they're travelling with all the write equipment.