Every agile software development process by definition requires periodical retrospectives in order to pause, have a look at the current practices and improve the way of working. There are two kinds of retrospectives: major retrospectives that happen at the product release or major milestone and minor retrospectives that are carried out at the end of iteration.

Iteration retrospectives

Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.

Project retrospectives

Project retrospectives are carried out at the end of the project or after the important release. The main goal is to improve the major issues. At this point team reflects deeper and gets chance to share its learnings with the whole organization. It is a good point to propose a new practice that would require a reasonable amount of learning and trials. Since project retrospectives presume major, possibly organizational changes, it is often ethically easier when the project retrospective is conducted by a third party and not a member of the team.