[kstenerud]

We do retros at the end of a sprint: midday Wednesday.

We use a trello board with the following headings:

- what didn't go well

- what went well

- ideas / discussion points

- show 'n tell

Everyone spends the first 5 minutes putting items for things they want to talk about. Then we go through them in order.

There's also an actions tab where we put anything important that arises during the retro. Those usually get turned into tickets or future meetings by the manager.

Usually there are 4-5 things that we discuss over 45 mins to an hour.

As far as I know everyone's happy with how they work (including me).

[al_borland]

We did something like this for a long time. We found it was helpful to change up the questions occasionally. People fell into a rhythm and didn’t have much to bring to the table. When this happened we’d throw in a retro where instead of “what didn’t go well”, we might ask, “what frustrated you”. Asking these slightly different questions brought some fire back to the retro and allowed us to surface some new issues and get them addressed.

Around the holidays we’d switch it up as well. We did a Festivus themed retro where we had the Feats of Strength, Airing of Grievances, etc. Things like that helped keep it interesting. I miss that scrum master…

[pypudding]

It's definitely great when done well. How about the tougher ones like incident retrospectives(or postmortems)? Is it also a team effort?

[kstenerud]

Yes. The premise is to sort out how human error led to the issue, and what we can do going forward to take human error out of the equation.

That can mean adding a script, modifying a program to take the human action part out, or even just a simple checklist.

Most of the time, a human mistake is a symptom of a bug in your policy & procedure.