The Technical Retrospective
If you are an Agile team and you don’t use the Spotify Health Check, you should try it. We do them once a quarter, and it gives us a different perspective on where we are as a team.
Valuable as it is, the Health Check is largely focused on ‘soft’ subjects; are we working well as a team? What’s our relationship to the wider business? Do we enjoy coming to work?
It doesn’t encourage us to reflect on the technical direction we’ve chosen for our major projects.
That feels like a gap. So we filled it with…
…the Technical Retro
If you’re in the Product Owning and/or Scrum Mastering racket, most problems can be solved with a quick Google.
We thought searching ‘Technical Retro’ would provide a variety of pre-canned options for reviewing technical choices as a team, but there wasn’t anything. So we made it up ourselves.
None of what follows is set in stone, though one thing we have found indispensable is an impartial facilitator with a technical background. You can get by without the Freddo Bars, but we wouldn’t recommend it.
Everything else is up for grabs.
The format described below is one that we’ve found through trial and error, and I imagine we’ll keep trying an erring for some time yet.
Principles of the Tech Retro
- It’s only for new stuff, not legacy systems
Why? For a couple of reasons. No one in the team was involved in building our legacy systems, and we only support them, we don’t make substantial changes. So an in-depth discussion about how they could be better would be a waste of time.
2. It’s project specific
Why? It’s not to discuss technology in the abstract (e.g. is Javascript better or worse than C#), it’s to make sure that we’re taking an appropriate approach to a particular project.
3. It’s only for substantial bits of work
Why? We don’t do it for short bits of work that are turned around in a week or two. The purpose is to make sure we’re getting the big things right. If we do that, then the results should filter down to our short term projects anyway.
4. These are not regular events
Why? Really an extension of point 3, but important to remember. Doing this properly takes a lot of time, so we can’t do them every week or month as it would be too disruptive. If you don’t have a specific large bit of work to discuss then you shouldn’t be having a tech retro. We’ve set an unofficial limit of three or four a year.
Things You Will Need
- A facilitator — this should be someone technical who is NOT working on the project under review
- A note taker — to take notes and keep time
- Sharpies, Post-its and a whiteboard — because this is an Agile retro, so its the law
- Freddo Bars
The Rules of Tech Retro
The following might sound like a bit of a faff, but it helped the team quickly identify common concerns and come to a consensus on what needed to be discussed.
Topics for Discussion
We cover these broad headings:
- User stories and planning
- Architecture
- Testing
- Deployment and Platform
- Monitoring
- Security
- System Performance
Round 1 — Happy/Sad:
- Everyone has post-its and a sharpie
- Use these to write up happy/sad notes for the project
- Stick these on a whiteboard
- Time-boxed to 5 mins
Round 2 — Subject Sorting:
- The facilitator writes the subject headings above the happy/sad post-it notes
- The team silently sort the happy/sad post-its into the relevant subjects
- Anyone can move any post-it
- Everyone gets a chance to look at the whole board before round three. At the end of round two the board should look like this:
Round 3 — Subject Voting:
- Dot voting part one
- Everyone has three votes to use at a subject level
- This allows to prioritise the BIG subjects (e.g Performance, Security etc.)
- These are then ordered for discussion by number of votes
Round 4 — Post-it voting and discussion:
- Dot voting part two
- Vote on the individual post-its under the subject with most votes (e.g Architecture got the most votes in round three, so we voted on the post-its under that first)
- Discuss the top three post-its under subject one in order of votes cast(5 mins each, which can be extended Lean Coffee style)
- Any possible actions should be captured during this discussion
- After third post-it is discussed, group votes to continue with current subject or move on to next most popular
- Repeat until the top three post-its of all subjects with at least one vote are discussed
- A subject with no votes doesn’t get discussed, even if it has post-its under it (sorry Performance)
Round 5 — Actions
- The actions captured in round four should be grouped on the whiteboard, not segregated by subject
- Another round of dot voting takes place to identify the top five actions
- The meeting isn’t over until we have at least one team member against each of the top five actions
