Friday, 20 November 2009

if (TeamProblems || !TeamProblems )
{
Retrospective.Start();
}

Luckily that title is as technical as this post is going to get. Recently our team have let retrospectives slip a little. We've all heard the excuses 'Too busy', 'not needed', 'no one's around' but those are exactly the right reasons for DOING a retrospective. Right I've already got ahead of myself here let's rewind a bit...

So what is a retrospective? A retrospective is generally thought of as a brief and informal get together (I hate the word meeting) to discuss what the team is doing right, what the team is doing wrong and how to fix some of the problems while maintaining the good stuff. The concept is part of Agile software development where teams develop through iterations or sprints, it's a chance to look retrospectively at the last iteration and try to do better - although we often don't get it right we should at least try.

But we're not doing Agile? Woah I didn't say it was exclusive to Agile. In fact I think you'll find it helpful without labelling it Agile or XP.

Sounds rubbish why should I bother doing a retrospective? Ok... good question! Retrospectives are great for providing team feedback. Maybe there's a lack of quality and you find yourself fixing bugs all day, perhaps important deadlines weren't hit or the team in general is not working to a sustainable pace. Flip this around and maybe the team is flying, code is shipped on time and doesn't come back - doughnuts all round. In either case don't you think it's important to work out what happened so it does (or does not) happen again?

Maybe I'll try it, so what happens in a retrospective? Hmmm tough crowd. Ok there are loads of blogs and books you can read that will give you 100 different tips on doing retrospectives. Our team decided to borrow a lot from the Scrum and XP from the trenches PDF, while AgileSoftwareDevelopment.com has some great articles and the pragmatic bookshelf published a good read on Agile Retrospectives.

Regardless of any material you read, the one rule I really think is important is that retrospectives are collaborative. Everyone should get a say good and bad about how the team is doing. But what if you've got some shy devs or a manager that is particularly bossy? How can you make sure everyone has an equal voice?

Something we've had success with is giving everyone a bunch of post-it's in 2 colours; one colour is for anything that was good about the iteration and the other colour is for anything bad. Each person spends 5 mins writing a few positive comments and a few that they think are negative.

For example - 'The deployment took too long', 'IIS settings were updated without any errors', 'Javascript bugs were found too late'. It's easy to be critical doing this so I'd suggest trying to write one good post-it for every bad post-it, it might not always be possible though!

After 5 mins writing on post-its (if something isn't thought about in 5 mins then is it important?) everyone stands up and sticks their post-its to a wall. As a team work out which post-its fit into a category, generally there is a common theme like 'quality', 'deployment' or 'IIS problems'. Bunch the related post-its together separating the good coloured notes from the bad. This gives the team very visual topics to discuss - 'Why are our deployments taking so long?', 'What can we do about the javascript errors?'.

Take some time to go through the good and bad notes for each category. If a post-it doesn't make sense ask the writer to clarify.
If people want to elaborate on points let them but don't push it. I believe every post-it on the wall is relevant because someone has gone to the trouble of writing it down. Discuss each one and talk it through.

Sometimes it's hard to remember key points or things that happened. In such cases you might find it useful to use a timeline to remember the last few weeks.

Once everything has been discussed the team can decide on 3 goals for the next iteration. Perhaps it would be to talk to the deployment guy more, maybe you've felt the javascript pain and know what to look for next time? Remember though - we're not LiveAid. No one is trying to feed the world here. Try to remain positive by keeping your goals relevant AND reachable. Print an A4 list of the team goals and stick them above your wall board so everyone can see them.

Ok I've gone on way too long now. Yes you have, what was the result of YOUR last retrospective big mouth? Easy rude boy... ok here are the goals from our last retrospective and to prove our team is not the elite Agile death squad we think it is, they are exactly the same goals as the retrospective before! Hey I did say we let retrospectives slip a little:

  • Increase clarity of through-put using the wall board
  • Improve scrums - yesterday? today? anything blocked?
  • Limit work in progress
Acknowledgments - Thanks to the following guys (and more that don't have a blog) who helped me realise retrospectives are awesome: Zubair Khan, Hemal Kuntawala and Mike Wagg.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home