How to Effectively Conduct Retrospective Meetings (Part 1)?

On a Scrum team, retrospectives may be done by everyone, but how do you do them well?

I. Eliminate misunderstandings

First we're going to name the retrospective:

1. Is the retrospective a project postmortem?

Although if you ask this question, everyone will answer no, but our little science will continue.Traditional project management uses post-project analysis to make system improvements, but this does not mean that retrospective meetings are equivalent to project post-analysis.What is the difference between the two?

• Different stages of occurrence: Retrospectives are encouraged to be conducted through Sprints throughout the project, so we usually do retrospectives at the end of each Sprint; post-project analysis is done at the end of the projector after termination.
• Different focus: The retrospective meeting focuses on continuous improvement during the project process and is a short-cycle feedback; the post-project analysis is to summarize the experience and lessons of the project process and carry out in the next project.Improvement is a long-term feedback.
• The output is different: The retrospective produces an execution path; the project post-mortem produces a document.

2. Is a retrospective a review meeting?

Again, the answer is no.Many people are not used to doing product improvement separately from process improvement, so they do it together.

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 Retrospectives are about team and process improvement and are primarily used toExamine how the team gets work done, decisions are made, and how members communicate.

3. Always the same agenda?

When we conduct retrospectives, we don't have to stick to a set process, because this process will gradually evolve into a mere formality, and the effect of the retrospective will be greatly reduced.The organization of the retrospective meeting is also provided below, so don't let team members habitually repeat it in retrospective meetings!

2. Essential elements of an effective retrospective meeting

1. Don't blame too much

"Whatever we found, we understood and truly believed that everyone did the best they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at handGood job." This doesn't really mean that everyone is blameless, and in the midst of too much blame, we may gradually become focused on the behavior of one individual rather than the behavior of the entire team.

Example: During a Sprint, the team found a bug.One of the team members rushed to fix and deploy, and while the issue was resolved, it also created a new, bigger problem.

In this case, we go too far into his personal reasons, and we may overlook some irregularities in the team, such as not checking the definition of "done", not running unit tests, etc.In this environment, team members are more likely to feel attacked than to admit that the original problem was solved.As such, they are less likely to learn anything from criticism, and most importantly, they may miss opportunities to delve into systemic problems.

III. Review form

1. Story Oscar Retrospective

Draw a box on the whiteboard where user stories are grouped into categories: best stories, most depressing stories, and most surprising stories.Teams come in retrospectives to post the user stories completed in the previous Sprint in the appropriate boxes via Post-it notes.If there are many user stories in each category nominated, then collectively select the best/most depressing/surprising user story among those user stories.

2. Sailing Retrospective

In this retrospective, we're on a small boat that's about to land on an island, and along the way, we'll encounter a lot of push and pull factors:

• Ship: Project Team;
• Island: Sprint Goal;
• Tailwind: what drives our Sprint to run smoothly;
• Anchor: What's holding us back from our Sprint;
• Reefs: Potential risks identified.
  Then in this retrospective, everyone has to analyze what our tailwind, anchor and reef are in this Sprint, and what we will do next in order to avoid the reef and put away the anchor in advancewhat efforts and plans.

With these tips, we can try to start a brand new retrospective, and we will have more ways to do retrospectives, so stay tuned!