I sometimes facilitate retrospectives for teams that don’t feel like they have the time to do retrospectives.

I know the feeling from personal experience: We’re in a toxic world about to crash to its doom. Coding is the protective suit we need to get the h— out of there. And it’s in short supply. Sitting in meetings feels like swimming in green, toxic slime.

No time to think

Skipping retrospectices is obviously silly. However, the same goes for sticking to your old format for retrospectives. Not that a proper retrospective couldn’t alleviate your situation and even get you into less of a hurry: There is always a potential irony that you don’t have time to evaluate your work, which keeps you from discovering the very problems that steals time away from evaluating your work.

The problem with sticking to the old retrospective format is that you will eventally stop doing retrospectives all together. In my definition of not doing retrospectives I also include 10 minute rants around the table before we get into iteration planning. As fun as they might be, rants don’t count. Although the latter is commonly used to describe the former, ventilation and retrospectives serve two different purposes.

So. If you don’t have the time to do retrospectives, my suggestion is that you do them anyway. In 15 minutes.

Here’s how:

1.  15 minutes before iteration planning, get everybody in a meeting room with a whiteboard (allocate 30 minutes the first time you do it). Any laptop or other disruptive device must be sleeping. Distribute a few post-its and pens to each participant and draw a podium on the white board.

2.  The warm-up excercise: Ask everybody to write down one thing that went well last iteration. After 2 minutes, read what  it says on the post-its. Do not allow any explanation or discussion.

3. The improvement storming: Ask everybody to come up with one idea that would improve the situation in the coming iteration. They might write as many as they like, but they’re allowed to present one idea only.

5. After 5 minutes gather around the white board. Ask everybody to take turn presenting their idea, sticking it to the whiteboard as they speak. Set the standard by starting with a team member you know as an efficient communicator.

6. Ask the team to pick a winner idea, along with a second and third runner-up. Place them on the podium drawing. At this point ideas might be combined or slightly refined. No idea may go on the podium unless one person takes the responsibility for reporting how it was implemented at the conclusion of the iteration.

Ideas are categorized as either practice (e.g. we should pair program more, we need faster stand-ups) or task (fixing the test data set, reducing build time, refactoring class Enourmous, etc). Task ideas go into the iteration back-log. Practice ideas are followed up by the team member responsible on the daily status meetings.

7. For subsequent retrospectives, exchange the warm-up exercise (what went well) with the question: “Which improvement tasks worked well, and why?”

The first time you do this you’ll need 30 minutes. When you get good at it, and you will fast, it takes 15 minutes. That’s good news, because let’s face it: Any decent developer can endure 15 minutes without a radiation suit. You couldn’t possibly have fought your way out of demonic mutants on Mars otherwise.

Good luck 😉