A technical retrospective

comments

Over the years of working with many teams, I’ve done tech retros (biweekly) and found them helpful. It’s like a sprint retrospective but focused primarily on technical debt and code issues. Here’s how it works:

We create a Trello board to which engineers add stickies with architecture/design/code parts that slow them down or make them frustrated.

At the tech retro we:

  • Review, clean, and prioritize the list.
  • Agree on who’s fixing what during the next 2 weeks.
  • The next retro begins with reviewing the results.
  • Repeat.

We cap the list to ~15-20 items. The limit represents how much we can actually handle in a few months ahead. It feels much better and also more effective than maintaining an inventory of 1000+ items, most of which will you’ll never have time to do anyway.

Don’t be afraid of dropping items; if something is important – it will return.

In the end, you have three types of tech work:

  • Technical work as part of a user story/business problem.
  • Technical work you can do when you have time/slack/buffer (tech retro work).
  • Continuous refactoring (aka The Boyscout Rule) is part of the coding process and need not be planned.