How to Run an Effective Retrospective Meeting?（Part 3）

After reorganizing the review's general process, we need to improve the retrospective meeting so that the team can think more efficiently in the retrospective meeting.

Systems thinking is very important in the retrospective meeting, because as individuals, without information and data, team members tend to make assumptions and conclusions based on their understanding and experience, but these assumptions and conclusions are one-sided or unrealistic. For instance:

The meeting scheduled for 10 o'clock had been delayed for ten minutes before it started. At this moment, Bob rushed in and started apologizing: "Sorry, I'm late! When I was about to leave the house, a stray dog ran towards me."

At this time, other participants in the room said:

• "Cool!" Liam said, "Would you take it in?"
• "That was scary, are you okay?" Joanne asked.
• Lan nodded and urged, "Alright, let's finish this meeting first."

The three men heard Bob's words simultaneously, but their reactions were very different because of their different points of concern. Liam had guessed that Bob might consider keeping this stray dog because he had wanted to keep a pet recently; Joanne had been bitten by a stray dog when she was a child, so she observed that Bob's clothes were wrinkled and messy, so she was worried if a stray dog had bitten Bob. But Lan had recently quarrelled with his girlfriend and had been unhappy when he went to work. This time he was a little aggrieved about Bob's lateness, but he found that others did not pay too much attention to Bob's lateness.

In this case, we can infer what will happen through the "Ladder of inference."

(Ladder of inference)

Image Source: Pinterest

The purpose of the inference ladder is that we can follow the key steps of this ladder without skipping or omitting certain key steps, ensuring that the conclusions we make are more precise.

When the team holds a retrospective meeting, the meeting sponsor can help members think better by constantly asking questions, such as:

• Have we considered all correlations? What might other dimensions be relevant to it?
• Are our observations based on a large number of data? Or do we accomplish this by looking at only a few pieces of data?
• What assumptions do we make? How should we test the existing assumptions? Why do we make these assumptions?
• Is this the only plan that meets our conclusions and goals?
• Can we ask others to explain what they think?

However, before thinking, we need to collect enough data into our information pool. In the above example, the information received by the three of them is what Bob said and what they observed about the wrinkled and messy clothes and the expression on Bob's face.

The information pool received by them is very small. Their thinking and inference are based on their experience in the limited information pool. Therefore, in the daily project management, when we review with team members, the first thing we need to improve is the breadth and depth of information/data. There is a risk of missing key information if we have very little observable data. Assuming that in the above example, Bob explained that it was a little teddy that ran over, then Joanne's worries would be dispelled, and other people would have more room to react.

The second thing we need to improve is our index. Before we set the index for team Sprint, we first need to clarify our index's purpose, which will help us determine which areas to focus on improving next.

If we set the index to "Are we providing users with the valuable features they want," that will determine that the features we make need to be verified by customers and fed back, improved, and delivered to meet their needs.

Then, after identifying the goal of improvement, we need to turn the slightly vague goal into specific actions. Firstly, we will ask team members to explain the value of this improvement goal and then specify which roles need to make these changes. Finally, we translate the goal into a step-by-step concrete and feasible operation to achieve this improvement goal. It should be noted here that if the workload of this improvement is large, it can be broken down into smaller tasks and then gradually improved in the next few Sprints.

For example: if the improvement we propose in the meeting is "limit work-in-process". Then our first action is to shorten the average development cycle. A further interpretation of this action is that we need to set a WIP limit for 4 tasks in the "doing" column. If we encounter problems in this process and there is a blockage of WIP, we can seek the help of others to solve this problem together. In this way, we have changed from a vague goal of "limiting WIP" to a clearer behaviour of "setting 4 WIP quantities and seeking help from others when encountering problems".

To complete the review more efficiently, we also discussed how to mobilize everyone's enthusiasm before, so I hope this article can help you think more efficiently in the review meeting.