Meetings have to be regularly with this type of teams. They provide the possibility to realize what’s the rhythm of its iterations or at least have an idea and reflecting about what are the most important events that had happen since the last time that were discussed or what’s the needs for the future. There is always improvements and decisions to make.
This is generally a set that facilitates, and there are a couple of formats established depending on terms such time aside for the meeting (It’s generally between one and three hours) and don’t forget that this is also a format that provides to all the opportunity to speak up.
Also Known As
This term is also known as the “sprint retrospective“, or “iteration retrospective“, often abbreviated, e.g. “sprint retro”.
The term “retrospective”, that was popularized by Norm Kerth , has gained favor in the Agile community over better known ones such as “debriefing” or “post-mortem”, for its more positive connotations.
The term “reflection workshop” from Alistair Cockburn ( even that is encountered less often) appears to have influenced the Agile Manifesto’s wording of the corresponding principle.
A retrospective is set to expose feelings or reveal facts that are important and can influence the team’s performance. Based on these observations are given ideas for next improvements. It will not be useful if it devolves into a verbal bout, or a whining session. On the other side, in order to be effective, everyone needs to feel comfortable to be open and speak up. The function of the facilitator is assure that this happens, that are lend conditions of mutual trust. For example, the presence of someone who is above, the whole schematic “hierarchical relationships” easily perturbs a meeting, people do not feel comfortable to speak what they truly want to speak if someone’s superior is around, It’s just nature. Perhaps It’s not always like that, but the facilitator takes care of the factors that may inhibit members of the team. A retrospective comes at a significant cost in person-hours if there is poor execution (factors like lateness, inattention or lack of preparation can lead to that) or can be specifically about the format (Lack of trust and safety) and that results in this practice being discredited even though all agile community disagrees. There is also an common mistake to not have the ideal number of iterations, mostly teams have too few or too many. The exact amount necessary It’s not more of one or two improvements ideas per iteration retrospective.
Sure It can be more, It’s just an estimation.
Signs Of Use
Take part in an observer role, to be ascertain the use of this practice and take notes of the improvements ideas and action teams (which are the outputs of retrospectives) in forms such as post-its summarizing ideas on the walls or written documents.
retrospectives leverage the benefits of iterative development: they offer explicit opportunities to improve the team’s performance over the duration of the project and also promote ownership and responsibility by the project team with respect to all aspects of the process; participants can understand the justification behind all process decisions. A safe space to build self-awareness by the simplest way: practicing.