I was pinged last night with a question about how to do retrospectives and what to be examining in the retrospective. I think retrospectives are a vital piece of any disciplined Agile approach. Working adaptively is really only effective with plenty of feedback and reflection. Actually, I’ll go farther than that and say that one of the biggest elements of success on any software project is the effectiveness and quantity of the feedback loops.
I also like using retrospectives and iteration planning meetings to bookend iterations. It’s just too easy to blow off iterations if there isn’t at least a little ceremony around iteration boundaries.
In shotgun fashion, here are my thoughts around doing effective retrospectives:
- Avoid the embarrassment meeting – I was a technical lead on a project that was effectively nothing but interpersonal tension and conflict. The project manager started every single iteration retrospective with a hugely painful comparison of estimated hours against actual hours for each and every story. It’s the kind of abuse I expect from traditional software shops when status meetings often involve a project manager collecting updates line by line on a Microsoft Project plan or Jira printout. Stop it. This type of meeting just sucks all the oxygen out of a team. I will personally pile drive any project manager that does this.
- Do reflect on your estimates – Avoid the embarrassment meeting yes, but it’s very valuable to examine your estimates. Early estimates generally aren’t very good because you’re making those estimates without the complete picture. Use the early estimates to adjust your later estimates for the following iterations. Improved estimates affords the project manager much more control over the delivery schedule. In the nasty project I described in the previous bullet, we used a release retrospective to completely change the way we estimated and ran retrospectives. The change in process, plus the empirical data from previous iterations, made the project much more tolerable.
- What do I retrospect on? – Everything. Think about anything that is slowing the project down. If you’re doing short iterations, it should be relatively easy to remember what was getting in your way in the past couple days. In a typical retrospective on my previous project we would discuss particulars of the design, how we were testing, and the interaction with the analysts. One of the best things you can do in a retrospective is simply ask “If you could change one thing, no matter what it is, what would that one thing be?” From our retrospectives we changed the way we tested the application (dumped FitNesse ), improved our interaction with the ultimate customer, and worked out the kinks in our design.
- The Spaghetti Western Format – My favorite way to do this is just to have one person go up to a clean whiteboard and write headers for “Good, Bad, and Ugly.” After that, open the room up for suggestions for all three headers. If you’re having trouble with participation, go around the room and make everybody add something to the whiteboard. At this point you’re brainstorming ideas. Write the list first, then discuss.
- Celebrate the good – Do not let retrospectives disintegrate into a wave of negativity. Yes, there’s always something that could be going better, but remember to talk about what *is* going right. This is also an opportunity for developers to share knowledge and experience about the things that are working. This new tool we’re using rocks. The developers helped me with some test automation thing. Our estimates were better.
- Identify improvements – Don’t just reflect, act. Come up with specific, concrete actions to make improvements. If you make any changes in process or design or tool selection as a result of a retrospective, come back and visit that change in the next retrospective.
- Make it safe – The retrospective has to be a “safe place” where anyone can discuss the issues facing the team. I think the most accurate way to measure the health of an Agile team is to watch their retrospectives and planning meetings. If these meetings are cordial and the team is willing and able to dissect their own performance without fear, you’ve got yourself a healthy Agile team.
- As much transparency as you can stand – Transparency is always good, but see the previous bullet point first.
- Everybody participates – I left this for last, but this is crucial. Sometimes you have the process and design that you deserve. Don’t be a spectator on your own project. Own the process. Own the technical direction. The retrospective is everybody’s job. The junior most members of the team may not have as much say in the direction of the project, but they’re still a set of eyes and ears on the project that has to feel the pain from any bad decision. In an earlier bullet point I mentioned a case where my team changed the way we captured estimates and did iteration planning that I credit with partially saving a failing project. That recommendation came from another developer, not from the project manager. Do not allow the project manager or lead to dominate these meetings because that will choke off the conversation (I’ll admit it, I don’t have a lot of good will towards project management in general. I think PM positions are largely filled by the Dilbert Principle).