Lean retrospectives for developers

phalt

Paul Hallett

Posted on February 14, 2020

Lean retrospectives for developers

They same time is money, but I hate that way of thinking. I think "Time is valuable" is a better saying. Getting the most out of people's time is important, especially when it is hard to get everyone into a room together.

I see a lot of people running retrospectives, and I see them resulting in very little value; just an opportunity to vent or raise issues. The lack of value comes from the fact that almost no time is given to creating actionable items out of a retrospective. People like to have their voice heard, but they value actions and results from being heard more. If it carries on without action, your retrospectives will no longer be valuable, and people will stop attending.

So if you're running a retrospective, how do you maximise the amount of value without having to learn the secret sauce of managing them effectively?

So here is how I run retrospectives, based off me running about 100 or so, and the experiences I've had with them.

I've found the best thiing is maximise the amount of time discussing issues and creating actions. Those actions can then be followed up, and most importantly: addressed at the start of the next retrospective.

You should be able to fit this into an hour comfortably.

Step by step

There are three phases to my retrospectives:

  1. Address previous action items
  2. Gather ideas
  3. Discuss ideas and write actions

First things first

Take one minute to remind everyone that retrospectives are a safe space to critically discuss issues. This is not a blame game, and if you really want to, remind everyone of the Retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

Address previous action items

5 minutes

Go through the list of action items you created last time. Explain what steps were taken to complete the action. If the action wasn't completed: ask if it is still important. If it is not important: drop it. If it is: add it to new Action list. If an action keeps being ignored, you have an issue that needs to be addressed outside of the retrospective.

Gather ideas

5 minutes

Ask people to write down their ideas on post-its. You can use whatever retro format you like. I prefer start, stop, continue.

After 3 minutes, ask people to start coming up and placing the tickets on a whiteboard or wall. People do not have to voice their opinion on their ticket yet. People can keep writing tickets until the five minutes is over.

As facilitator; I like to start grouping tickets into topics during this time. Chances are people have similar feelings about the positive and negative things happening in the team. The only section that will be different is the ideas section.

Discuss ideas and write actions

50 minutes

This section is where the value of retrospectives is hidden. So I try to maximise the time spent here.

For each topic; summarise it to everyone. Chances are you are aware of the topic, so you can give some extra context if you like. Do not ask people for their voice or opinion on each topic yet.

Once summarised, start with the negative section (like stop). People often pick the positive topics to discuss first, I think it is best to leave that section to the end. For each topic, summarise what people are feeling. Ask the group: "Does anyone having anything more to add"?

Now is the time to start discussing this topic. As a facilitator: I try to find opportunities for actions that can help solve the issue in this topic. Propose ideas to the group or encourage people to suggest ideas.

I find if I spend more than five minutes discussing a topic then it usually won't get much further. So as a facilitator I try to reach a decision on an action in five minutes. If people feel like more time is needed for that topic: then the action can be "Have a longer discussion about topic X before the next retro".

Once the negatives are out of the way, start discussing the ideas. Usually one person will suggest one idea, so encourage them to explain their idea more. I find that the actions from this section usually result in someone trying out the idea and reporting back to the team before the next retrospective.

Finally, I summarise the good points. This section is usually around team wins, production deployments, feature launches, or other successes. They're a great way to end a retrospective and they usually don't have actions.

Wrap up

To wrap up the retrospective, I summarise the actions that are to be taken. I will try and assign each action to a person. Shared responsibility is good, and there is a higher chance actions will be completed. I usually take a photo of the post-its or write them down, and send around an email summarising the whole meeting. This email becomes the list you read from at the next retrospective about what actions you had previously.

Easy

There you have it: my lean retrospective without any magic or fluff. It's straight to the point and designed to maximise the time. Feel free to copy and paste this idea fully, or take the parts that you find valuable.

💖 💪 🙅 🚩
phalt
Paul Hallett

Posted on February 14, 2020

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related

Lean retrospectives for developers
retrospective Lean retrospectives for developers

February 14, 2020