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

Original

Organizing a well-run retrospective meeting can help the team improve and take the next step, so how should we conduct an effective retrospective meeting? The following are some things that need to be focused on, and mastering the following elements will not only help the team improve efficiency and increase enjoyment but also gradually reduce or eliminate misunderstandings about Scrum.

I. Clarify the Basic Rules of the Meeting

Clear meeting rules should be part of the teamwork agreement. Ideally, these rules are specific to behavior (for example: "state an opinion and ask real questions") rather than abstract (for example： "respect"). At the same time, the team should create, maintain, and own these rules.

How do you determine these basic rules？

Team members can try to recall the best or most effective retrospective meetings they have participated in recently. After everyone has described the advantages of these meeting modes, we can determine the common modes of these meetings together. These common modes are the potential meeting rules.

II. Everyone can Express Their Thoughts in the Retrospective Meeting

In most retrospective meetings, a simple method is needed to stimulate members' interest or motivate them to express their opinions. One popular method is the "voting method": we can give everyone on the team the same number of ballots (using stickers, sticky notes, etc.) and ask them to vote for the most important and best behavior or task in their minds. If team members think a task is particularly important, they can choose to give all their votes to one task or distribute their votes to multiple tasks.

Image Source: graph

III. Who Needs to Attend Team-Level Retrospective Meetings

The retrospective meeting at the team level should involve the whole team. Only the Scrum Master, the product owner, and the development team should participate in the retrospective meeting at the team level. Others may want to participate, but their presence may reduce the team's open, honest, and reflective ability.

IV. Duration of Sprint Retrospective Meeting

The purpose of the retrospective is to help the team celebrate all the things that are going well, give feedback, and improve what needs to be adjusted for the next Sprint. Typically, a retrospective should be held at the end of each Sprint, and the Scrum Guide recommends a three-hour retrospective for a month-long Sprint. However, in my experience, it is more effective to set aside one hour per week for the Sprint, which means that a two-week Sprint is worth a two-hour review.

V. Create a Meeting with a Clear Structure

A retrospective meeting can consist of the following phases:

1. Sign in

We mainly need to invite the participating members to the meeting room and make them feel that the retrospective meeting is distinct from the previous review meetings. We can start by doing an activity that helps to perceive the mood or energy of the team.

• ESVP ice breaking

  Anonymously, people can tell their thoughts about holding a review meeting. They can choose the one that suits them best from the following four Tags: Explorers (eager to acquire new knowledge and want to participate actively), Shoppers (in a shopping mood, it is OK to buy good things, and it doesn't matter if they don't have it), Vacationers (very casual, there is nothing they want to get), and Prisoners (forced to participate). If most people are vacationers or prisoners, the meeting organizer can consider discussing why there are negative emotions within the team during the retrospective.

  

  
  

Image Source: graph

• Weather (mood) report

  We can draw on PPT: sunshine, clouds, rain, and storm. What each person symbolizes should be self-evident. We can ask people to mark which they think fits better.

2. Collecting and Summarizing Data

At this stage, it is necessary to summarize and sort out the information generated during the retrospective meeting. At this stage, we need to list what happened without immediately judging or identifying what needs to be improved.

It is worth noting that a lot of work in this stage needs to be done before the meeting officially starts: for example, preparing the number of stories completed in this iteration, the number of bugs found, the burnout chart, Kanban, and other information and abnormal points.

3. Conduct Analysis

We can analyze it with the data collected in the previous iteration. First, we need to ensure that the team can spread their ideas as much as possible and then analyze and find areas for improvement.

In this stage, we can help you spread your thoughts through a small game: we can divide two areas on the whiteboard: "what aspects of this iteration do I like?" and "how to make this iteration better?" Each member of the team can write their ideas in these two areas. After completing this work, you can screen these ideas.

4. We Need to Decide What to do

For many people, this is the only part of the retrospective meeting that seems to be taken for granted because we are more likely to want to get involved and solve problems. At this stage, the team will decide how we can make the most important and effective improvement to the next iteration.

We can use the SMART principle to constrain the next improvement measures: specific, measurable, achievable, relevant to other goals, and with clear deadlines. In other words, our next improvement measures should conform to the SMART principle. Under this premise, each team member can write 2 improvement measures, discuss them, and select the most important and least changed improvement measures.

5. End of the meeting

This is an opportunity for the team to reflect on themselves. We can think about: what have we learned from each other in this iteration and this retrospective meeting? And how can we become better in the subsequent process?

The above structures are not necessarily the form that the review meeting must follow, but sometimes making some new attempts at the retrospective meeting may be able to help everyone collide with new sparks.