Retrospective

Retrospective is a short and regular meeting where the team members reflect on past events and plan the future Sprint. Read more about effective retrospectives you can have.

What Is a Retrospective

A retrospective is an opportunity for the team to inspect itself and create a plan for improvements to be included in the next Sprint. It is a time-boxed meeting, outside of day-to-day routine, to reflect on past events and behaviors. Retrospectives strongly correspondent with the philosophy Fail Fast.

The retrospective was mostly popularized by Scrum. Now it is commonly used by other agile practices, such as Extremely programming (XP), Kanban, or Lean Development. In none-agile environments, retrospectives are sometimes done after a project is finished to generate “lessons learned as a post mortem”.

In the basic form it answers three questions:

• What worked well?
• What did not work well?
• What will we commit to doing in the next Sprint differently?

Why You Might Want the Retrospective

• Higher team performance Retrospectives contribute to the benefits of iterative development. They offer opportunities to improve the team's performance during the project. In addition, they allow understanding the reasons behind project decisions.
• Promotion of ownership and responsibility Retrospectives encourage collective ownership and responsibility of the project team. That is why agile promotes the usage of retrospectives to help them to solve problems and improve themselves.
• Problem-solving approach "It is insane to do the same things and expecting different results." - Albert Einstein. Solving problems and subsequently delivering more value to your customers requires a change in the way of working.

Problems the Retrospective Helps to Solve

• Demotivated team
• Increased cost
• Meaningless work
• "Not my problem" mentality
• Expensive development
• Toxic Team Culture
• Disconnect Between Business and IT

How to Implement the Retrospective

1. Arrange an (ideally regular) meeting Invite the whole Scrum team (the development team, Product Owner and Scrum Master). If you have a specific topic that includes people from outside the team, they can take apart as well. The Sprint Retrospective is generally regular and takes place after the Sprint Review, before the next Sprint Planning. Most often it lasts an hour and a half for two-weeks Sprints. For longer Sprints, the event is usually longer. The meeting is usually facilitated by the Scrum Master.
2. Set the stage Present the agenda and remind the time-box of the meeting. Set the interval which one is the scope of the retrospective (for example, the previous Sprint or the whole project). Give people time to switch on the right mood. Tip: Use icebreakers! They allow the team to get into a creative thinking mode and forget about everyday problems.
3. Remember the past Remember together the basic events of the previous period.
4. Gather data Help the team create a shared pool of feedbacks. Tip: The simplest practice is the game "Good/Better". In other words, ask the participants to write down on a particular post-it an answer on the questions:
   • What worked well?
   • What could be improved?
5. Determine the most serious impediments Group (negative) feedbacks by topic and let the team vote the most serious issues. Tip: There are many types of voting. One of them is “Dot voting”: each participant has three votes and can place more than one vote to a group. Each vote is represented by a dot. The groups with the most votes will be picked up first.
6. Generate insights and decide what to do You have chosen the most serious issues to work. Create concrete action steps of how you will solve the issues. An action plan should contain a next action, a responsible person, and a due date.
7. Close the retrospective It is time to do “a retrospective of the retrospective”. For example, think together about how could you the retrospectives improve or what was the most beneficial point of the meeting.

A good source of retrospective "games" is Retromat.

Source: Our own Retrospective Meeting

Common Pitfalls of the Retrospective

• A blame game Retrospectives are not designed to assigning blame or “ass coverage”. Focus on the utility of the outputs for the future.
• Trusted conditions An effective retrospective requires that each participant feels comfortable speaking up. The facilitator is responsible that there are the right conditions, for example, a mutual trust or such factors as hierarchical relationships. The participation of a manager may inhibit discussion.
• Next actions missing Identical issues coming up at each retrospective may signal that the retrospective has become an empty meeting. Do not forget about a measurable action plan and pay attention whether it is followed. Otherwise, participants will not have a need to confide the team.

Resources for the Retrospective

• Scrum Guides: The Scrum Guide
• Retromat: What Is a Retrospective
• Wikipedia: Agile Retrospective Resource Wiki
• Agile Alliance: Heartbeat Retrospective
• Medium: What are the Benefits of Agile Retrospective Meetings?
• Fun Retrospectives: Dot Voting