Four years after I originally wrote this it is still getting hits, since that time I’ve written a much better post: Agile Retrospectives
“Retrospective Agility” by Tim MacKinnon (part of a long pdf – too bad you can’t easily link inside these beasts) is a great starting point for running a retrospective. I was trying to find a short description of an Agile Retrospective to share with my team when I stumbled across this article. Tim has some excellent ideas especially for those of us just starting down the path of holding retrospectives.
Key Ideas:
- Create Safety – how to create a safe environment for developers to say whats on their mind.
- Types of Retrospective: Iteration, Incident, Release, Project
- Lists of Common Things that went Well and Common Things to Improve – these could be very handy as a starting point for teams that don’t have much experience do retrospectives.
I just wish that more of the ideas mentioned in the article (like Gold Cards: intended to allow programmers to work on tasks of their own choice leading to increased innovation and a higher sustainable pace on the project) had been defined in the paper itself. It made the paper difficult to read on the bus ride home.
Over all Tim’s article made for a great introduction to Agile Retrospectives while I’m waiting for my copy of ” Agile Retrospectives: Making Good Teams Great” (Esther Derby and Diana Larsen) to arrive.
As for the description, in the end I wrote my own (feel free to reuse it):
What are Retrospectives?
A meeting where a team looks back on a past period of work so that they can learn from their experience and apply this learning to future projects. Traditional waterfall driven projects normally hold these meetings after a release or some other significant event. Following the original description (Norman Kerth ” Project Retrospectives: A Handbook for Team Reviews“) these were 3 day offsite events.
Agile Retrospectives/Reflection?
Agile retrospectives differ from Kerth’s approach by being held at the end of every iteration and by being short thirty minutes to two hours (they tend to get shorter over time). They involve the team, management and the product owner. The scope includes: Reflect on the product: did the Product Owner get what they wanted, etc.; Reflect on the Team’s Progress: What did we accomplish? Was it what we set out to do; Reflect on the Team’s Process: What worked well and what worked poorly?
What Retrospectives aren’t
Blame fests/Witch-hunts – Retrospectives aren’t about who did what wrong – they’re about what the team can do to improve
Many of ideas for this description were taken from Alistar Cockburn’s “Agile Software Development: The Cooperative Game (2nd Edition)“