We've been doing a heartbeat retrospective at the end of every 1-week iteration to reflect on our team, our methods and our interactions. Our iteration review concludes at 5pm on a Tuesday and the last thing we do is the retrospective. They've been taking around 30 minutes and have basically been a facilitated group discussion focusing on what we did well and areas for improvement. From the retrospective, we took no more than 2 action items (sometimes user stories), targetting a specific thing to improve on, into the next iteration. This perhaps sounds good enough, and we do continue to improve, but I don't believe we've been getting the most out of our retrospectives. What's worried me for some time is how frustrating these retrospectives have become for everyone involved.
The iteration before last was a tough one and the retrospective was particularly frustrating for everyone. The next day, following our iteration planning game, I wanted to revisit the frustrations with the team so I went out, got some chocolates and fruit, and when I got back I called a timeout. We had a good discussion, which turned naturally into the retrospective for the previous iteration. It was a very reflective and productive session.
First, everyone said they could offer more in the retrospective if they had time to 'decompress' after the iteration and sleep on it. Since our iteration planning games were taking 1 hour or less, we decided to hold the retrospective immediately before the planning game for the next iteration. It's important to conduct the retrospective before the planning game so that you can take new knowledge and any actions (or user stories) into the next iteration. Giving up 1 hour of the next iteration to conduct a better retrospective for the previous iteration was deemed worthwhile.
Second, as the saying goes 'action begets action'. We decided to extend the retrospective to 1 hour so that we could include activities that would spice things up, get people moving about and inject some energy into the experience.
Third, we decided to take only one thing, the most important thing, into the next iteration that would help us improve in a chosen area. We wanted a single focus and we felt that other important things would recur and probably surface in the next retrospective, just 1 week away.
Today, we completed our first new-retrospective before our planning game. It was fun, vibrant, focused, very reflective, and we came out of it with a single objective, which we took into the next iteration as a user story. The nucleus of the new format essentially follows James Shore's retrospective and I've added a check-in to open the session and a ROTI assessment to close it. Here's the agenda:
Norm Kerth says: The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive. Set the stage by reading the Prime Directive out loud and then, in turn, ask each person to say whether they can agree to it.
2. Open - Check-In (5 min)
Get everyone to check-in to the retrospective by asking each person to say in one or two words how they feel about the iteration. This way everyone says something from the start and it helps people to continue to be vocal and involved throughout the retrospective.
3. Brainstorming (20 min)
Paraphrasing James Shore: Ask the team to think back to the iteration and brainstorm the events that were enjoyable, frustrating, and puzzling, and consider what you'd like more of, less of, and to remain the same. Write each idea on a separate post-it note and don't worry about duplication.
This is a variation on affinity mapping but without speech. It's a lot fun devising various ways to communicate with people without talking. Semaphores. Gesticulation. Hand signals. Eyebrow maneuvers. The goal is to group related post-it notes, assign each group a name, and then dot-vote to identify the most important group to improve on in the next iteration.
Given the most important group, ask the team to brainstorm 6 ideas for improving it. The team should select one course of action, by consensus, and take it into the next iteration as an action (on the team's action list) or as a user story. In our retrospective, our most important group was 'build'. Our various builds (continuous integration, nightly, site, performance tests, uat) were vying for processor time and people felt that the plethora of cruisecontrol projects were complicating the overall build schedule. We took a user story into the next iteration to rationalise the cruisecontrol projects.
Our frustration levels sparked this change to our retrospectives, so I like to close the session with each person, in turn, stating a number from 0 to 4 that reflects the return on their time invested. 0 indicates a low return. 2 breaks even. And 4 indicates a high return. The numbers are recorded on a histogram. I ask those people who rated the retrospective 2 or higher to say what benefits they received. Here's our histogram:
Previous Topic
