How to Run an Effective Retrospective Meeting?（Part 1)

Original

In the scrum team, everyone may be doing the retrospective meeting, but how can we do it well?

1. Dispel Misunderstandings

First, let's explain the retrospective meeting:

1) Is the Retrospective Meeting a Post-event Analysis of Special Cases？

Although you will answer no to this question, we will continue to explain it to you. Traditional project management will improve the system through post-event analysis of special cases, but this does not mean that retrospective meetings are equivalent to post-event analysis of special cases. What is the difference between the two?

• Different stages of occurrence

The retrospective meeting is encouraged to be conducted throughout the Sprint during the whole project process, so we usually hold the retrospective meeting at the end of each Sprint; Post-event analysis of special cases is conducted after the project is completed or terminated.

• The focus is different

Retrospective meetings focus on continuous improvement in the project process, which is short-cycle feedback; Post-event analysis of special cases is to summarize the lessons learned in this project process and improve in the next project, which is long-cycle feedback.

• The output is different

The output of the retrospective meeting is the implementation path; the output of the post-event analysis of special cases is the documentation.

2) Is the Retrospective Meeting a Review Meeting?

Again, the answer is No. Many people are not used to separating product and process improvement, so they combine them.

Sprint review meetings provide an opportunity for the development team, product owner, Scrum Master, and stakeholders to review the product and make improvement decisions, while retrospective meetings are about team and process improvement and are mainly used to check how the team completes work, makes decisions, and how members communicate.

Image Source: Graph

3) Is There Always the Same Agenda?

During the retrospective meeting, we need not stick to an established process, because this process will gradually evolve into a mere formality, and the review effect will be greatly reduced. The organizational form of the review meeting will also be provided below. Don't let team members habitually repeat in the retrospective meeting !

2. Essential Elements of an Effective Retrospective Meeting

1) Don't Blame Team Members Too Much

"No matter what we find, we understand and truly believe that everyone has done the best job they can, taking into account what they knew at that time, their skills and abilities, available resources, and the situation at hand." This sentence does not mean that everyone is blameless. With too much blame, we may gradually focus on one person's behavior rather than the whole team's behavior.

For example, in a Sprint, the team found a bug. One of the team members was eager to repair and deploy. Although this problem was solved, a new and larger problem also emerged.

In this case, if we investigate his reasons too much, we may overlook some irregularities of the team, such as not checking the definition of "complete" and not running unit tests. In this environment, team members are more likely to feel attacked than admit to solving the initial problem. Therefore, they are unlikely to learn anything from criticism. Most importantly, they may miss the opportunity to study systemic issues in depth.

3. Retrospective Form

1) Story Oscar Retrospective

Drawing a box on the whiteboard where user story stories are divided into several types: best, most depressing, and most surprising. The team comes to the retrospective meeting and posts the user stories completed in the last Sprint in the appropriate boxes via sticky notes. If many user stories are nominated in each category, then the group collectively selects the best/most depressing/surprising user story from these user stories.

2) Sailboat Retrospective

At this retrospective meeting, we take a small boat about to land on the Island. During this process, we will encounter many factors that promote and hinder:

• Boat: project team.
• Island: Sprint objectives.
• Tailwind: factors that promote the smooth progress of our sprint;
• Anchor: factors that hinder our Sprint implementation;
• Reefs: identified potential risks.

Image Source: Graph

In this retrospective meeting, everyone needs to analyze our tailwind, anchor, and reef in this Sprint and what efforts and plans we need to make to avoid the reef and collect the anchor in advance.

With these tips, we can try to start a brand-new retrospective meeting. Next, we will have more methods for retrospective meetings. Keep following us !