How to best conduct and document agile retrospective meetings?

Question

I have worked in organisations that used either one of the following approaches during a retrospective meeting to gather feedback and reflect on how the agile team is doing and to explore ways to improve:

First approach:

“Start”, “stop” or "Continue"

Using this approach each team member is asked to identify specific things that the team should:

• Start doing
• Stop doing
• Continue doing

Second approach:

What went well and not so well?

Using this approach team feedback focuses only in these two areas and team feedback is captured as follows:

1- Capture feedback in excel sheet

2- Team Vote

3- Tackle highest voted items "in what didn't go so well"

4- Decide on actions

---

Which approach to use:

Using the “Start”, “stop” and “Continue” approach, the retrospectives meeting seem to take longer time but does provide substantially more feedback. However, documenting the outcome is a bit problematic because the list of items (particularly the “start”) keeps growing!

Using "What went well and not so well" approach the outcome of the retrospective meeting seems to be more focused but less rich.

I understand that a combination of these two approaches is perhaps possible by starting the retrospective with: What went we’ll and not so well! Followed by “Start”, “stop” and “Continue”. I haven’t tried it before. So I have a couple of questions:

1. Has anyone used a combined approach and how successful was this?

2. What are best practices when it comes to documenting retrospective meetings with both these approaches and with a combined approach?

Answer 1

The Retrospective is a key ceremony and, IMO, it is critical to approach the process in the right way.

I use the traditional format of

1. Set the Scene
2. Gather Data
3. Generate Insight
4. Decide Action
5. Close Down

All told there are somewhere in the region of 80-100 potential activities that can be used across each of the five stages although some activities have become commonplace.

---

My Process

This a completely subjective approach may can be used to inform your own retrospectives.

Context

A full Scrum Team in a Business Intelligence environment working within a corporation using waterfall for most projects. Team consists of Scrum Master, Line Manager/Architecture Expert, Product Owner, Deputy Product Owner, Developers.

As the Scrum Master I have banned management from the Retrospectives in order to give the team privacy and assurance they can speak without retribution.

I aggregate and anonymise all data before presenting a transparent actions report following the meeting. All developers are protected.

Set the Scene

Each participant is provided with an A4 sheet for making notes and also asking 4 questions.

• Question 1 is for the start of the Retrospective. Do you consider yourself an Explorer | Shopper | Vacationer | Prisoner > Tick One

I then pose a verbal question.

• Why do we do Retrospectives > Pick one individual and ask them to reiterate
• What do you want from this Retro > Pick one individual and ask them to reiterate

Normally with a question to the team I use the technique Pose, Pause, Pounce and nominate someone to answer.

Gather Data

For this aspect I have a round-robin of activities but the most effective has been listing the Agile Principles and asking the team to note on post-its examples of where they get it right / wrong or where we focus on the items on the right more than the items on the left.

There are over 40 different ways to gather data regarding the previous Sprint or timebox. As a Scrum Master you should maintain a list of your preferred options and the latest thinking on the subject.

---

Break for coffee

---

Generate Insight

A considerable number of ways to generate insight (40+) also exist however the traditional methods include the 5 Why's which is extremely popular.

Decide Action

Traditionally the Stop, Start, Continue method has dominated the Retrospective ceremony however you can also use a Low Hanging Fruit tree with "fruit" being replaced with actions which are ranked according to speed and impact. You can use dot voting, roman voting and other consensus building methods.

Close Down

At this point I like to get feedback on my facilitation skills so I ask the team to refer back to their A4 page and answer the remaining three questions anonymously.

• I Was Heard > 1 being absolutely not and 10 being very much so
• This Was Useful > 1 - 10
• Things will get done > 1 - 10

In addition you can ask the team to volunteer for actions in order to drive through the change and own the team's improvement.

My final action is to turn the entire thing into an Infographic and post publicly for all to see whilst checking the status of the action items.

I have included some of the examples I use below

Answer 2

With my team, I typically follow the following approach with three rounds and it works well for us:

Round 1 - What went well and what could have gone better individually

This focuses on each person's individual tasks and the wins/misses with respect to their work alone. It facilitates some introspection with every person involved.

Round 2 - What went well and what could have gone better as a team

This allows each person to comment on the wins and misses for the team as a whole (or other individual members). This allows broader shortcomings to surface while at the same time allows team members to be appreciated by others for the work they did.

Round three - How do we work on what didn't go so well

This is a broader discussion with the floor open. Here, we take the misses identified in the first two rounds and discuss them. This includes both the individual misses as well as the team misses. It lets every issue identified be scrutinised by the entire team to arrive at a possible solution.

Answer 3

I practice retrospective meetings with my groups that develop either hardware or software or full systems. I tend to prefer the "what was good" - "what was bad" approach. The reason is that it motivates people to identify positive actions too and focus on what we experienced instead of dreaming of ideal but non-existing world.

The main thing I added is a second dimension to motivate wider thinking by listing categories on which I expect an input (this is not exhaustive, but used as stimulator). I typically include categories like "design methodology", "tools", "suppliers", "support from management", "schedule", "team work", "initial specs", "change management", "risk management" ... and if the team works on full systems and include managers, I will directly take the knowledge areas as defined in pmBOK.

The documentation of the meeting is firstly an excel spreadsheet (for detailed tracking of ideas) and then, after rework with the full team or with only a part of it, a Word document listing important lessons learned, sorted in categories, with an action list where each action is backed with a ticket in the quality system to make sure that there will be a real action.

Answer 4

Start, stop, continue strikes me as jumping straight to the resolution of the problem without first discussing what the problem is.

I use the what-went-well/went-badly approach. The whole team gets to contribute in the first part of the meeting, writing on post-its. This is to make sure that the more introverted members of the team do not get influenced by what the stronger characters say before they have generated their feedback.

We quickly run through all the feedback and then we group the feedback post-its if any of them share a common theme. Usually 1 or 2 topics will really stand out and will be mentioned my several members of the team. Next we decide as a group which item we want to do something about in the next sprint. To me this is where the start/stop/continue bit comes in, but it is focused around one potential improvement rather than across all the feedback.

At the end of the meeting I will write-up the post-its on a wiki page and distribute it widely. I see the main value of this is that it demonstrates to the wider organisation that the team is focused on self-improvement. It also acts as an escalation for issues that are covered in the retrospective that are outside of the control of the team.