Once a disciple asked the Master, “How long should I wait for changes for the better?”

“If you wait, you should do it for a long time,” said the Master.

The truth is there is no need to wait for anything. Sprint by sprint, the team is working on the project, but where is the point where we could think the changes over and take a step towards them? And this point is a retrospective.

Some theory

“Why do we need retrospectives?”

It is a frequently asked question. Sometimes in a marathon of infinite development, it is necessary to look back and think if everything is as good as we would like it to be. Perhaps the team members have suggestions/ideas on how to improve the code and design process, perhaps there were difficulties somewhere and we can do something to avoid them next time and so on.

To do this, it is nice to get together and discuss these things.

“Well, you can also send suggestions in letters and discuss them by mail”, once I heard this suggestion. It seems to me that this approach takes incomparably much more time and effort (as compared to one-hour meeting once every iteration) + in an endless chain of letters it is easy to miss rational ideas, everything is stretched over time, it is inconvenient to vote in a mail client and so on.

“What kinds of retrospectives exist?”

• after every sprint (local improvements, better to say, short-term improvements);
• after the end of the project (long-term improvements, time for global changes).

“Who to call?”
As a minimum, the team (developers, test engineers, analysts, Project Manager). A good reference point is a meeting for planning, it is desirable that all those who usually take part in it, attend a retrospective. If there is an opportunity to invite the Product Manager do it, it will be good both for him and for the team. If the Product Manager speaks English, then hold the entire meeting in English: he should be fully involved in the process.

“What about duration?”
In my opinion, a 1 hour meeting after a sprint or 1.5 hour meeting after a completion of the project is enough (or I just don’t like long meetings  🙂 ).

Some practice
So we finished our sprint (successfully or not) and gathered to analyze what went well and what not quite well.

The retrospective is divided into the following main stages:

– Set the stage (introductory part);
At this stage, you need to welcome everybody and sensitize to productive work. We usually set a sprint goal, and the first thing we do is to check if we reached it or not. Another important point is the revision of the action plan from a previous retrospective (what was planned and what was done, what works for us and what doesn’t and so on). 

– Gather data; 
At this stage, it is necessary to recall, what was successful in the last sprint/project, and what was not successful (difficulties and problems faced by the team) and what would you like to improve. You should remember that it is impossible to solve all problems at once. If there are many stickers with negative comments, it is necessary to choose the most important aspects by voting (the easiest way is to have 3-5 points from each team member).

You can also compliment some of the team members for their excellent work and just write down ideas for improvement.

– Generate Insights (analyzing casual relationships);
At this stage, it is necessary to analyze why there were difficulties, what were their causes and only after that proceed to the final stage.

– Decide what to do (deciding what to do next with everything mentioned above);
Finally, we decide what we can do with all of this: for example, we can’t influence some problems, but most of the problems can still be solved. At this stage, we write an action plan (specific actions) for each point, assign responsibility and set a time limit (usually within the next sprint, but it depends).

– Close the retrospective. 
In conclusion, you need to thank everyone for their participation 🙂

Personal experience

• Meetings should not be boring. Diversify them as much as you can;
• Try to make every retrospective as informal as possible, so people will be glad to participate, and they will be full of ideas;
• Before you start, you can conduct an interesting activity for the team (it will improve communication between people and increase the degree of trust);
• Make forms/questionnaires, which can be distributed at the beginning; it does not take long, but it gives objective attitude of the team to the process/tools/technologies;
• Use a variety of methods of data collection (starfish, sailboat, mad/glad/sad/afraid, fuel/sandbag/bad weather, etc.);
• After the meeting, send everyone a report with a brief summary + new action points + action plan with the performers, because stickers usually get lost, and people forget everything quickly 🙂 Don’t forget to print out a new action plan and hang it in a noticeable place, mark completed action points — it is a great motivation!
• Sometimes I want team members to learn something new, and at the beginning of the meeting I try to tell information that might be interesting for them 🙂

Results

Oh, I can’t even remember how much we have done this year. We have solved problems with estimates, with analysis of requirements of dependent products, with a support; we have made mandatory a practice of code review (in order not to be tempted to skip it, it is 50 UAH per commit without the code review), we have improved demo holding, replaced part of regression testing with an autotest, started to use risk management, developed a common test strategy for our product and stick to it (unit, integration, UI, security, load testing), we have begun to write using TDD, defined Definition of Done and follow it when evaluating the degree of task completion + solution of operational tasks on the spot.

Also during this period we drew portraits of each other, the state of our project, found out who likes to walk in the mountains and who likes pistachio ice-cream 🙂

What can I read?

1. Agile Retrospectives. Making Good Teams Great / Esther Derby, Diana Larsen
2. Project Retrospectives: A Handbook for Team Reviews / Norman L. Kerth
3. Scrum and XP from the Trenches / Henrik Kniberg
4. Project Retrospectives: Evaluating Project Success, Failure, and Everything in Between / R. Ryan Nelson
5. Retrospectives – Learning Not Just Repeating / Tim Mackinnon
6. Look Back in Agile: The Sprint Retrospective / Alan Bustamante
7. http://www.slideshare.net/prowareness/techniques-for-effective-retrospectives
8. http://msdn.microsoft.com/en-us/library/jj620912.aspx
9. http://keyholesoftware.com/2011/12/23/anatomy-of-a-retrospective-part-three

P.S. One day I was inspired by @andreyzt, thank you! If you don’t have retrospectives try to setup the first one, it’s really helpful for team, but do not make it like “one more boring meeting” 🙂