brainbaking/content/wiki/reflect/retros/retrosurgery.md

+++ title = "retrosurgery" draft = false tags = [ "reflect", "retros", "retrosurgery" ] date = "2013-03-12" +++

Retrospective surgery

See http://retrospectivewiki.org/index.php?title=Retrospective_Surgery

About

This type of retro really focusses on the retro of the retro. It's obviously something you shouldn't do every retrospective but it can result into a lot of interesting topics on how your retrospectives are actually doing.

The retro should take about 60 min and people should work in pairs or ideally groups of 3.

Contents

First part: discovering the bad parts about your retrospectives

Divide everyone into groups of 3 (or 2 if you must). Give them a block of post-its and a pen, and ask them to write down everything they think could be better in your team's retrospectives. This can range from too long retro's to not enough or too fuzzy SMART actions, ... (timeboxed 10-15 minutes)

Second part: making the bad parts go away

Break down each group of post-its for every group into 3 and divide them - make sure everyone has something different right now.

After that, again give everyone 10-15 minutes to come up with solutions to the problem noted on the sticky note. Let them write on the backside.

Third part: summing it up

Group post-its together by theme on a board. Everyone was a bit surprised that a lot of people actually had encountered the same problems. We came up with these groups:

1. time related: retro duration/when in the sprint to plan the retro?
2. people related: who should be invited? (Business? OPS?) How to mention a problem without making someone angry?
3. SMART Actions related: too much planned, too little done? Who's responsible for them?

There will typically be some lonely outliers like someone who complains about the usefulness of the waste snake, someone who thinks developers have too much "power" in the retro because the ratio dev/proxy isn't even, ...

Make sure to discuss the biggest groups if you run into time trouble!

Every possible solution on the back of the sticky note can be translated into a SMART action or a reminder for the next retro - place them somewhere visible so the team can see them daily.

Examples of concrete reminders

• No retro with business yet -> Plan an extra, specific retrospective, for the business + PO & after a production release with operations
• Too much actions as result -> maximize SMART action points to note (5?) & put them into the swim lanes! They're impediments after all.
• Are people still to shy to say something? -> keep the "beginning-of-retro-relic" - 1 sentence/speaker max.
• Waste snake is waste and not really useful -> discuss the waste snake during retros and regulary mail results to program management
• no-one picks up SMART actions? -> put them into a lane for visiblity instead of board and assign someone DURING the retro
• sometimes too much useless discussion -> put up your hand if you think the discussion should stop to keep up the pace (signal)
• some retros are too focussed or not focussed at all -> cycle normal iteration feedback retros & broader retros + introduce "lessons learned" retro after a project

Last part: discussing previously held retrospective themes

Write down every kind of retro you've had in the past. Discuss with the whole group:

• What worked, what didn't work out so well?
• What took too long? What contains a lot of "bad" things you discovered before?
• How can you modify some themes to apply the positive bits?

Ask everyone their top3 retro type. We discovered the following ranking:

1. Mad/glad/sad: 6
2. Molesststoco: 4
3. Like to like: 4
4. Speed dating: 3
5. Retro surgery: 3
6. Discussion about one specific topic: 1
7. Fishbone: 0
8. Agile radar: 0

A lot of people really liked the classic formula's of using post-its to discover "bad" things, and discussing them. Like to like also has some elements like this, as does speed dating. Everyone really liked the retro surgery but it did not get a lot of votes because it's not something for every two weeks.