A Product Team story: The Technical Retrospective

calendar Jan 3, 2023 |  2 minutes  |  Lars Hjornholm tech it
Share on: linkedin copy

I'm the product owner of a platform engineering team in BESTSELLER. Our team is responsible for building, maintaining, improving, and delivering several software components that go into our company's DevOps toolchain. It's a potent mix of home-developed, open-source tools and COTS (Commercial off-the-shelf) offerings.

We have approximately 110 active developers utilizing the DevOps toolchain and relying on this to be fully operational at any given time - to be able to do their work. But whether it's a business software product, a DevOps toolchain, or a mobile app - they have at least two things in common.

  1. They are built by developers. Developers are subjected to tight deadlines, changing business demands, impatient POs, and the surprising "Remember to pick up the kids" alert on their phones. As with any other given human being on the planet, developers can also be complacent, feel uninspired, and be "sloppy" from time to time. Let's be honest - it happens as it does for us all.
  2. They all have technical debt at some point in time during their lifecycle. Dependencies get updated, vulnerabilities emerge, or a developer takes a shortcut to make the deadline. In any software product, you'll find some kind of technical debt.

All of the above is absolutely normal. It's the life of a software product, and it's the reality of many organisations - big or small.

So how do we deal with tech debt?

Our team quickly realised that carving out time to address technical debt would be of value to our products, stakeholders, users, and ourselves. We work with SCRUM and have 14-day sprints. We strive to keep the sprints 80% for stories (planned work) and 20% for slack time (ideation and unplanned work). But here's the exception - July & December are allocated to what we have called "Technical Retrospective". In other words, no delivery of features to our stakeholders.

"Technical Retrospective" starts with brainstorming with all team members. Here we go through the components that we know or feel could contain technical debt. During the brainstorming, we create stories for each piece of debt. Instead of giving it story points, we prioritize it - from a severity POV. The more vital the component is - the higher the priority.

After that, the team started bringing down the debt, and at the end of the retro - we've hopefully covered a lot of ground, have increased the quality and reliability of the solutions, and given our stakeholders, users, and ourselves a better starting position for the coming six months.

About the author

Lars Hjørnholm

My name is Lars Hjørnholm. I work as a Product Owner for BESTSELLER TECH's amazing Engineering Services team.

In my PO role, my passion and vision evolve around making BESTSELLER's development organization work as fast, efficiently and securely as possible while having a ton of fun doing it.