Tweet 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...