Everyone who has been part of an Agile team would be very familiar with retrospectives. Usually retrospectives are done on a project level or a sprint level.
But today, I am going to take you through a retrospective that is designed to reflect back on the tech details of a project and how we can share those learnings to the wider team.
What is a tech retrospective?
A tech retro is very similar to a project retro/Sprint retro but focuses more on the technical side of things. It is an opportunity for the tech team who worked on the project to get together and look back at some of the key decisions, arch patterns and challenges they faced.
Once a tech retro is done for a project, the discussion points and learnings are documented and shared with the wider tech team.
The output is formatted in such a way that it is very easy to digest. The intention is to make it easier for everyone to benefit from the learnings even if they have not been part of the project.
- Outline of the project — what was the problem we were trying to solve?
- Architectures and basic design patterns used.
- What tech decisions went well and what didn’t?
- Some of the challenging tech decisions eg: Arch changes due to change in scope etc.
- How easy was it to onboard new devs into the team — did we maintain a Readme?
- Tools used for analysis — static analysis / cyclomatic complexity etc. What was the general trend of the results?
- Testing approach we took and how did it go in general — unit testing, code coverage, TDD etc
- Tech debt — where do we stand in the quadrant?
- Here are some of the topics you can include in your tech retrospective to have a productive discussion.
- Did we do root cause analysis for bugs? What were some of the common root causes for the bugs?
- Was it easy to build new features on top?
Other observations / recommendations
- Any new frameworks, 3rd party libraries, tools, techniques used
- Documentation
- Gitflow hygiene
There are often more topics that we may discuss in the tech retrospective and it varies with projects.
Why do we need it?
We are often looking for ways to improve our knowledge and experience. The beauty of being part of a consultancy compared to a product company is that we are always surrounded by teams who are working on different projects. It is important to identify how we can effectively share that knowledge and learn from each other’s experience. Tech retro is something that definitely helps you do that.
How do we run it?
There are many different ways to run it — you can even make it similar to how you run your Sprint retrospectives. We usually have the topics listed in a template Trello board, which is shared with the team. The project team would create a copy of this to run their own tech retrospective. Once it is done, it is shared with the wider team during their platform catch up.
How often?
It is beneficial to run it when there is a logical stop like a milestone release or a project end. For an ongoing project, running a tech retro once every 3–6 months would be better.
Tech retros are really easy to run and can be incredibly beneficial for your entire team. Spending just one hour on a retro helps your team learn from each project whether they have been part of it or not and make better tech decisions in future.
Let us know your thoughts on tech retros.
