Retrospective or Sprint Retrospective

Share!

The word "retrospective" comes from the Latin "retrospicere"which means "looking back". In film, television and literature, a technique called "flashback" - or analepsis - is used to connect different moments in time and further develop the character of a character or context.

In this sense, the practice of retrospective meeting makes a lot more sense to me, and rises above the primary feeling of getting better. The agile team is like an individual who creates a personality and a character. And hindsight seeks to develop that character.

If you still find the concept complex, I invite you to reflect on the role you have in each of the social and family groups of which you are a part. In some groups you may be the oldest or the youngest, the most cheerful or the most serious, or the most disciplined and disorderly. In this sense, the team is a space where all members assume a role and a position that has room to mature and strengthen according to the objective for which we form the group.

Retrospective meetings

Retrospective meetings are, in essence, a space where the entire team reflects on past performance - the last day, the last presentation, or in the case of Scrumthe last Sprint.

The purpose of the reflection is only one, taking clear actions to improve team spirit and performance.

Terms associated with retrospective meetings

• Agile Retrospective - agile retrospectives
• Sprint or Iteration Retrospective - sprint retrospective. In the particular case of Scrum, the Sprint or iteration context seeks to limit the reflection to the period immediately preceding or about to be completed. However, in practice I recommend focusing the discussion on the previous period, but leaving space to evaluate or contrast the impact of decisions from other retrospectives. For example, assessing the positive or negative impact of a decision or action plan from the immediately preceding - or preceding - retrospective.
• Retro
• Heartbeat retrospective^[1]The translation of heartbeat retrospective is very difficult to translate literally into English..

History of Retrospective Meetings

Please don't think that someone invented the practice of hindsight within the context of projects or agility. However, this specific practice that I will call "agile retrospective" has an origin that we can trace as follows:

Benefits of Retrospective Meetings

I can say a lot about the advantages and benefits of retrospective meetings. However, I want to make it clear that all these benefits are directly dependent on our continuous improvement model.

What good is a retrospective at the end of a project if the project is already ending, what value can I capitalize on within the project or with the team? In truth, the practice of the retrospective meeting requires cadence^[2]Rhythm or repetition of certain phenomena, such as sounds or movements, that occur with a certain regularity. RAE. Without cadence, the exercise of reflection loses its greatest potential, transforming a team and the work they do.

The 5 key benefits of retrospective meetings are:

1. Retrospective meetings facilitate transparency

Give the team - or multiple teams - the space and time to identify problems or challenges, come up with solutions, and take ownership creatively. accountability and empowers teams. At the same time, it makes the making of various management decisions transparent and makes us all "responsible" for the work culture itself.^[3]Although the term organizational culture represents something more complex, habits and actions are ultimately a clear expression of culture. Modifying habits and actions can, over time - and cadence - transform culture..

Team members can discuss team problems and situations, while sharing their experiences and ideas on how to improve. This helps to build trust and psychological safety.

2. Agile retrospectives promote collaboration and good communication.

Retrospectives create a safe environment where team members or the organization can give feedback about their modus operandi. Offering this space on a regular basis has a substantial and positive impact on collaboration between people. Trust is established and, if well oriented, a culture of constructive criticism and teamwork is established.

Not in vain, the 14th State Of Agile Report evidence that agile retrospectives are the second most used agile practice (81%) and increased team morale is considered one of the five clearest benefits of adopting agile management models.

Frequent retrospectives, combined with a governance model that listens and takes action, strengthen collaboration and good communication.

3. Team Retrospectives Promote Respect for Processes

We can't lie, software developers - and in general professionals in careers related to software engineering and application layout - are not lovers of processes. Or even of following rules just for the sake of it.

When we actively participate in decisions we become engaged. This promotes respect for the process and for the decisions we make as a team. Even if they are not decisions we would have made ourselves.

This respect for process and "good manners" helps a faster adoption of models such as Scrum, or even to create team identity. Ultimately, it promotes productivity increases and strengthens teamwork.

4. The Agile Retrospective are an early warning system

One of the most important benefits for high-risk environments is the fact that these types of meetings create a model of risk managements and quality assurance. A retrospective has a quantitative analysis and a qualitative analysis of the results which, if done correctly, creates an ideal space for risk management and assurance.

Retrospectives allow the team to evaluate what was done well, and what was not done so well, and in that sense to attack at the source the origin of some risks and, of course, to improve the quality that results from a mature process.

5. Retrospectives Promote Technical Excellence

We have talked about the processes and the spirit of the team. However, retrospectives are also a space to rethink the technical result. And I don't mean the functionality of the product. I mean how the result has been developed and what improvements - and what the product has been able to achieve. refactor - we can evaluate to ensure a better result.

Ultimately, technical excellence is the result of reviewing and evaluating the "forms" and "models" we have used to solve a certain process or a specific need. Retrospectives allow the team, in a safe space, to discuss those things they are not proud of - technically - and which, in the future, may be a source of problems.

Structure of an Agile Retrospective Meeting

What is the structure of such a meeting like? What activities can we do? Here I tell you how and I leave you some exercises that you can do to make the most of this time.

The retrospective meeting can be structured in 5 - sometimes 6 steps. As follows:

Moment 1: Preparation, opening or welcome

During this time, the moderator or facilitator sets the tone for the meeting. For example, if we come from a good cycle with good results, it is a time to celebrate without forgetting that we can improve. However, if we come from a cycle of bad results or unfulfilled promises, it is a time to reflect on our mistakes or even those things that made us assume in the past that everything was going to be better. The tone will define the rest of the meeting. But remember, we are not here to point fingers! We are a team. We are meeting to look for solutions and opportunities for improvement.

Moment 2: Metrics and Objective Assessment

Once the context is established, it is time to look at reality. Data is our best ally to focus the discussion on facts and results and less on people and subjective opinions. This part of the meeting is called in Scaled Agile: quantitative analysis. If you're using other practices like velocity or defect density, it's a good time to present that data - and your history.

Moment 3: Discussion and understanding of what happened

What happened? How did we perceive the cycle? was it a good one? was it a bad one? what went wrong with our assumptions and plans? what worked? For the last question to resolve I would leave the why? All of us need to build a structure to justify the results. If you jump to this question from the start, everyone will try to justify their answer with a story that is often subjective and not necessarily connected to the data.^[4]In the book "The Code of the Extraordinary Mind"Vishen Lakhiani refers to the term "meaning making machine" in reference to our brain. As a facilitator, I recommend you mitigate the influence of this human behavior..

Moment 4: Decisions based on the improvement of the team and its productivity.

With discussion comes understanding, or at least a unified group view of what has happened and is the perfect opportunity to weigh in on opportunities for improvement and specific actions we can take as a team to improve.

And, let me make a recommendation for moment 4, don't allow the team to make too many decisions. If a team commits to too many changes, it may be impossible to determine in the future what actions really made a difference.

Make two or three decisions about how to improve during the next cycle.

Moment 5: Conclusions

Of course, you can imagine that some meetings are very intense. It's time to tone it down and bring the team back into the context of continuous improvement. And therefore, always remind the team that nothing is personal and all criticism is contained within the team with the intention of keeping it private and focused on improvement.

Extra Moment: Evaluation of previous results

It is often prudent to review with the team previous decisions from other agile retrospectives. And then, the team builds a greater understanding and awareness of the impact of their own improvement decisions. Did the decisions from the immediately preceding iteration work? Did they contribute to productivity as we had hoped or not?

Practical Tools for a Good Agile Retrospective

Of course, there are hundreds of practices and exercises that we can do for each of the moments of the meeting. Here is a list of the three that I like the most - and that have given me the best results with my teams.

1. ESVP

For the preparation stage, I like to do an activity known in English as ESVP - Explorer, Shopper, Vacationer, Prisoner. The goal is for each attendee to assess his or her disposition and perspective of the meeting. These "positions" are:

1. BrowserA person who is willing to learn. You have a spirit oriented to personal and team growth.
2. BuyerJust like when you walk into a grocery store looking for something. You are not willing to go through every shelf to see "what you find". You don't see everything as useful or necessary. Therefore, as a buyer you evaluate what you like and what you keep.
3. VacationerWhen you are in this position, you are really escaping from other responsibilities. That is, hindsight is a break from other things. Therefore, your intention to collaborate or exert yourself is practically nil.
4. PrisonerI don't know how much explanation this position requires. But if the vacationer is escaping from other responsibilities, the prisoner could not escape and is obliged to participate.

It should be noted that this technique is anonymous.

2. Standard Metrics

From the beginning of the work with the team, I like to establish a set of metrics and indicators that allow us to improve. Not for nothing is there a saying "what you don't measure, you can't improve". In this sense, I have defined a basic set of metrics and a complete article about it.

I always like to graph these metrics historically. That is, as a sequence of values. I invite you to read my article about agile metrics.

3. Starfish or Starfish Technique

This is, by far, by far, my favorite. Not only is it a powerful tool, it's profoundly simple. The goal is to invite team members - or the participants of an activity in general - to present their ideas and feedback of that activity. To do so, they must associate their idea with one of the following categories:

1. Keep / MaintainIt is something that they liked and they feel that it has contributed to the activity. It is something that they feel should be maintained in future activities.
2. Stop / Stop or stopOn the contrary, the ideas or comments left in this category represent things that were not liked or should be discontinued because they do not add value to the activity.
3. Start / StartIn this category we include the things that we would like to start doing or that were missing in the activity.
4. Less / MenosThese are tools, activities or techniques that may have been overused or overdone. For example: "fewer follow-up meetings" or "fewer pair work sessions" could be examples.
5. More / MoreLess: Contrary to Less, this category means that you want more of something, of an activity or an attitude, or more of a technique. It means to go deeper or to do more of something.
6. KudosThis is a category to highlight someone's work or congratulate someone or something. It is vital to keep clear that, beyond the difficulties of the work itself, there is always room to recognize the work of the team, the company or a person.

Other valuable resources for retrospectives

Of course there are plenty of tools to make good retrospectives and keep the focus on what's important. Here is a list of useful tools and sites with examples of other activities you can do.

• Tasty Cupcakes - Perhaps not the best name for a website, but this is a community that grew out of a presentation in Toronto in 2008 about agility.
• Fun Retrospectives
• Easy Retro

Most common mistakes when implementing agile retrospective practice

In closing, I leave the article with some of the most common mistakes and problems prone to occur during retrospective meetings.

1. Forget the purpose of the meeting. The goal is to improve, and to do so, we must discuss the deep things and not just the superficial symptoms. Therefore, within the meeting structure, at the time of "preparation" it is prudent to establish the objective.
2. Making too many decisions. Decisions or action plans are not bad. But too many can lead to paralysis or even chaos. Changes and improvement actions should be introduced a little at a time, to ensure that the team goes through its own growth process and does not try to make quantum leaps.
3. Not having the tools to promote discussion. This is a typical mistake of inexperienced facilitators, arriving at the meeting without sufficient preparation or clarity about the tools to use. Without tools, the discussion can be poor or, worse, disorganized. A good facilitator does not assume the success of every event or activity and prepares to "lead" the team.

Share your experience

I would like to hear about your experience during agile retrospective meetings. I'd love to hear what worked for you and what didn't work. To the best - or funniest - comments, I promise to send you a -digital- gift.

Don't neglect to do the retrospectives, and be as committed to them as you are to a planning session or a refinement session of the backlog. The success of truly agile teams is that they don't stop and always want to improve.

Share!