Eight tips for better retrospectives

I am often surprised at how many self-described agile teams don't hold retrospective meetings every iteration. For those team that do hold retrospectives, I often find they have a lot of room for making them more effective. An attitude of continuous improvement is fundamental to successful teams, and the retrospective is the primary mechanism for improving, so it follows that effective retrospectives are one of the key elements of a good agile team.

In this post, I offer five tips on how to conduct more effective retrospectives.

1. Review notes & actions from the previous retrospective

This is step #1 in the retrospective, which of course implies that you must first record notes from your retrospective meetings. (See tip #8) Use a projector to display notes & action items from the past meeting. Keep it short - five minutes at most. If you have remote team members, use a webinar and/or video conferencing so everyone sees the same screen. If you find your team bringing up the same problems as in previous iterations, ask why - five whys, actually (see tip #5).

2. Ask what problems, successes and opportunities you have with the team, the product, and the process

The facilitator will ask the team, "What did we learn about the team, the product, and the process? What were our problems, successes and opportunities to further optimize?" Capture these items in a grid as shown below. Use a white board if everyone is in the same room, or take notes in a wiki or other electronic document - preferably the same one you'll use to archive your retrospective notes (See tip #8).

	Problems	Successes	Opportunities
Team
Product
Process

3. Let each team member speak without discussion

The facilitator gives each team member the opportunity to speak without any group discussion; no one else is allowed to comment on anyone's opinion - yet. Only clarifying questions are allowed at this time. Discussion will come later when the team is discovering the root causes of problems. (See tip #5)

4. Vote on the most important items to take action on

You may not be able to immediately address every concern raised in the meeting, but you certainly need to prioritize them. Every team member is allowed to vote for 3 items that he/she believes are most important to take action on. Tally the votes and add the items to your process improvement backlog based on priority. Note that some items may not require any further action. Even successes may need action however; for example, a good pattern or practice may need to be documented in the Definition of Done or added to the coding standard.

5. Use "five whys" to discover the root cause of problems

For each of the highest-priority problems identified, the facilitator will ask "why did that happen?" Once an answer is given, ask the same question again, repeating the process five times. This should lead you to the true root cause of the problem.

6. Create an action plan for your top priority items

For each top priority item, decide what to do, and who can do it - which may be more than one person. Any actions requiring work by team members should be planned and assigned during iteration planning. (See tip #7) Actions assigned to members outside the team must be coordinated and scheduled. Of course the action plans should address the root causes of problems, not just the symptoms.

7. Explicitly allocate time for improvement actions

Maintain a backlog of improvement actions. At each iteration planning, pull the top improvement actions into the iteration. Improvement items should be prioritized along with product backlog items based on overall value to the organization, but teams should reach an agreement with the product owner on a percentage of their time to be spent on improvements.

8. Record your retrospectives & actions

Maintain two artifacts: (1) a process improvement backlog and (2) retrospective notes. The notes may be captured in real-time during the meeting using a wiki, intranet, or other electronic document. Record just enough information to support a review at the next retrospective (tip #1). Appoint someone other than the facilitator to take notes. For the process improvement backlog you may use the same tool you use for product backlogs; this backlog can be owned by the scrum master.