Retrospectives – What is it and how to get started?

In his famous book "Project Retrospectives", Norman Kerth has defined retrospective as an opportunity for the participants to learn how to improve. The focus is on learning—not fault-finding.

Retrospective rituals are more than a review of the past.  They also provide a chance to look forward, to plot the next project, and to plan explicitly what will be approached differently next time


In their book "Agile Retrospectives, Making Good Teams great", Esther Derby and Diana Larsen has defined Retrospective as

"It’s a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so."


What a Retrospective isn’t?

It is not a postmortem.

Why we call it as a retrospective and do not call it as a Post mortem? Post Mortem is something, which is done on something dead.  We are working on projects which are live. This has to be done at regular intervals.

It is not a Ceremony

Do not do it for the sake of doing it. Identify techniques which can make it fun, so that everyone participates and the team identifies areas of improvement. 

It is not a secret

Its not a meeting where you can point fingers/blame others. The purpose is to identify where the team is lacking and how we can improve as a team. The meeting can include all kinds of stakeholders (provided understands the purpose of the meeting)

It is not session to Whine.

It is definitely not a place to Crib. Emphasis is on being constructive.

It is not a place to blame others

Emphasis is on "I/We". Its not a meeting where you blast your customer side representative or the customer takes it as an opportunity to blast the team.


How to run/facilitate retrospectives?


Before the Meeting

Setup a Meeting with Team members and all the stakeholders. Its very important that the stakeholders also attend the meeting.  Have a meeting room setup for the discussion.

If your customers are in a different location, setup WebEx/LiveMeeting, Conference (Video Conferencing will be really great. Depends on the availability and Budget :))


Identify a template where you will capture the events and share it with all stakeholders (It will really help if your customers are in a different place).


In his book "Agile Project Management with Scrum", Ken Schwaber says the meeting should be time boxed to 3 hours. My interpretation to it is defined based on 30 Days iteration.


In my experience, for a 2 weeks sprint with a team size of 10, the retrospective could take anywhere between 1.5 to 2.5 hours.


Get some Snacks/Cookies for the team. Because my customers are in a different time zone, we will do it in our evening/their morning hours. If there is a need to stay late, cookies/snacks will help the team to be energized.


During the Meeting

Step 1: Start with Norm Kerth’s Prime Directive for Retrospective. In our meetings, the whole team (here team includes the customer side architect and other stakeholders) reading the Prime Directive loudly once.


"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time,  their skills and abilities, the resources available, and the situation at hand"


Step 2: Define the Ground Rules: Our Team ground rules are something like this

1. Do not finger point or blame others

2. We all are responsible for the success or failure of this

3. Try to attack the problem and not the person

4. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.                


Step 3: Decide the facilitator.


Step 4: Appreciations: Team members to appreciate/recognize other team members who have helped them in 2 weeks. It helps in bonding. Make sure, the appreciations are captured and shared with stakeholders. Team members will definitely feel happy to see their name in that. May be it’s a collection of "Whale done" or good things everyone has noticed for 2 weeks.


Step 5: Once you are done with appreciations, move to the actual questions section.


Answer the 3 questions. Purpose is to inspect how things are and adapt ourselves accordingly.


1.    What worked well?

2.    What needs to be improved?

3.    What should we do differently?


You can change the format. We call it as "Mad (Crazy), Sad (Needs improvement) and Glad (Did Well)".


Step 6: Identify Lessons Learnt. We try to gather this from the GLAD, SAD and MAD sections.


Step 7: Identify Top 1 or 2 Actions items which the team is going to work in the next 2 weeks. Identify the Theme for the Area of improvement and the Action Superstars for the Theme.


After the Meeting

Share the Retrospective meeting notes with all the stakeholders.

Share the progress the team has made with the action items identified in the previous sprint with all the stakeholders.

Sharing the Retrospective notes could be in email, wiki, posters or any other format. Our team sends the report in email and keeps the copy in SVN.

The Scrum Master will follow up on the Action Items Identified.



1.    Making the team participate.

2.    Everyone focusing on "I/We"

3.    Continuously identify area of improvements and working on them

4.    Creating a Learning Organization/Environment. Making it as a part of the organization culture.



The purpose is to create a learning environment, where everyone in the team and as a team learns and improves continuously. If retrospectives are conducted to its true spirit, the team will identify the recurring mistakes (patterns) and will work on improving. It helps in identifying the best practices and sharing the knowledge across the organization. It helps the team to prepare for the future.

Underlying theme: What can we do better next time?



Project Retrospectives: A Handbook for Team Reviews

Agile Retrospectives: Making Good Teams Great

Sustainable Software Development: An Agile Perspective


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s