What is a good plan for a retrospective to show its purpose?

Question

Background & assumptions:

• the team has 4 developers + team lead
• some of them participated in retrospective meeting before, some didn't
• the team would like to start doing retrospectives and asked me to do it one-time so that they can continue
• I'll be gone forever when the meeting is over
• team lead would like to carry out next meetings

Please don't assume any process framework the team is following. I've used the word retrospective to indicate that the purpose of this meeting is to improve the development process and collaboration.

What would be the best usage of their 60 minutes?

Answer 1

Try the Start/Stop/Continue method for retrospectives

There are many ways of doing retrospectives. But I have found the Start/Stop/Continue method very effective in surfacing the right issues and allowing a constructive discussion.

This exercise is a great way to pause, be mindful, reflect, and take action. We use the Start/Stop/Continue method to discuss processes, values and behaviors at work. I initially thought that it was corny but have learned to embrace it for its simplicity and results...

Answer 2

Introduce Concept, Collect Data, Analyze Information, Decide on Actions

Start by reminding the team why you are holding the meeting; your goal is to discuss your production process and improve the method by which your team builds your product. Also be sure to let the team know that the meeting is held under the assumption that everyone did the best job they could with the information that they had at the time--this isn't a blame session, or a time to vent your spleen. You are looking back over what happened with the benefit of hindsight, so it's important to ensure that no one treats this as a meeting to place blame or to get defensive.

With that preface, move into collecting data. One of the easiest ways, since you won't be working with the team in the future, is to have everyone put a few items in a list of what went well and a list of what they feel they could improve on in the future. Make sure everyone contributes--it's the best way to ensure buy-in.

Take the points that your team has put on the board and move through them one by one. As the facilitator, it's your job to ask questions to get the team to think deeply about the root causes of problems as well as the things that led to items that went well. I generally record this information in meeting notes, but sometimes there are discussions that don't need to be recorded (e.g., one member of the team being uncomfortable with another. If this is the case, it's worth bringing up as a data point of your own and having an open conversation about it.)

Finally, the team should decide on actions to take. Many teams take the approach of Start-Stop-Continue-More Of-Less Of. Each team member contributes one action to each of these categories, again on the whiteboard, and then the team takes a vote. I have team members each "Adopt" an action--while all team members are responsible for the actions that they choose, that one in particular should push the team to achieve the improvements that they've discussed.

I think I've covered the basics here--happy to answer any questions or discuss other ideas!

Answer 3

as you may know also, there is no right or wrong answer as every team is different and most importantly, as you said, the purpose of the retrospective is to improve upon team's performance gradually.

I have been with team with few version, and i am sharing the one that I personally like more because it is easy to understand/follow and good fit for team where all team members are not much familiar with this concept.

there are three parts:

GLAD: Let the team call out all events from sprint they feel good about

SAD: Let the team call out all events from sprint they do not feel good about

Action: Let the each team member vote for 2 things from SAD list, and then pick top 2 items with the highest vote as Action Item. But most important here is Let the Team decide how they want to proceed with those action item. they have to propose the actually actionable steps to accomplish those two things.

Do not forget to followup on Action items from last retrospective.

Answer 4

I think, at the simplest form, it could be splitted into the following parts:

1. Introduction about why it's good to have retrospectives, what are expected from members of the team
2. Collecting topics that cause problem in team's work (brainstorming, priorization, documenting them)
3. Deciding upon what should be done to resolve / mitigate top n impediments, assign responsibles and deadline, etc.

After the first meeting, first topic could be replaced by a short status about the action items decided in the previous meetings. So it can be simply another kind of assignment that should be carried out by the team member - the difference from the regular ones is first that it operates on process level, instead of deliverables level, and second, there should be less pressure about those items (in best case most of the work items will be handled by the team lead / PM / scrum master).

Answer 5

I agree with much of what it said here. One way or another, the point of the retrospective is to find ways to improve the development process. Any number of methods described by others on this question can be used to identify action items.

However, the most important thing is to ensure that there is action taken based on the discussions. I've worked with many teams where a whole list of things are highlighted as part of the "start/stop/continue" method, however, nothing is actually done.

I've dealt with this in the past by requiring the team to select one item from any of their lists and actually do it as part of the next sprint.