Technical debt, when not handled correctly, can have a big impact on the ability to deliver features. Through the years, my team has tried out a lot of different ways of dealing with technical debt. The following 5 findings are the things that I think helped us the most in dealing with the right technical debt at the right time.
1. Pick up what you can immediately
When I joined my team, I was explained the boyscout/girlscout rule. When you're working on some part of the codebase, you should always leave that part in a better way then you found it. It's like cleaning up after yourself, and then some. This way, you can gradually make small improvements that add up over time.
2. Create a backlog
When you apply the boyscout/girlscout rule, you will often find improvements that are so big that they would take longer than the feature itself. For those improvement opportunities, we have a separate backlog. This backlog is maintained by us as developers, but visible to non-developers. A great way to make this backlog more tangible is by creating a Wall of technical debt.
You'll notice that as you discover more technical debt, your backlog will slowly grow. Especially with a physical backlog, there is clear feedback when your backlog gets too big.
3. Prioritize your tech debt backlog
Not all technical debt is equal. Some of it prevents you from adding a nice feature easily. Some may wake you up at night because something broke. Some technical debt is just there, where you don't really notice it that much.
It is important to make sure that the technical debt you're solving helps in achieving business results. We prioritize our technical debt stories once every sprint. When we do, we look at what we are going to work on in the upcoming sprints. We also look at which technical debt stories have been open the longest or might be creating a high operational load on our team. We then choose which stories will provide the most value to pick up right now.
I've noticed also how important it is to prioritize together. Before we did this, we would all be working on improving something, but often on different parts. By discussing openly why we thought some improvement was important, we got everybody on the same page. And we improved the prioritization itself as well, because we could use the knowledge of the whole team to make these decisions.
4. Handle tech debt stories as normal stories
For the longest time, we would handle technical debt as something special. Something that you reserve a Friday afternoon for. Something that you do off the books. This special treatment has a couple of bad side-effects:
- It isn't clear how much time is going towards improvement efforts. When we don't make the sprint, is it because we spent too much time on technical debt?
- To prevent too much time going to improvement efforts, we would schedule some time in our agendas. This often results in half finished improvements. There was quite some time wasted by starting again where you left things a week later.
- Improvements would not be tracked on our scrum board. This makes it hard to know who is working on what, if they might be blocked or need help.
Estimating our technical debt stories the same way we do normal stories has helped in scoping what we want to improve. It also allows us to take the time needed to finish whatever we put in scope. And we can track progress the way we do all other stories, which allows detecting any blockers or problems early.
5. Spend time regularly on technical debt
Picking up technical debt should be a regular thing. This way, you'll never have to completely stop delivering value. To make this work, it is important to break down big improvement efforts into smaller parts. In a lot of cases, we have first investigated or made proof of concepts to get a better understanding of what to do.
Google famously has a dedicated one day per week in which engineers can work on anything they want. We've noticed that by consistently spending 20-30% of our time on improvement efforts, the remaining 70-80% of time has gotten more productive. This only really works if you apply all previous points. Without an open technical debt backlog, with business value based prioritization, it is hard to build the trust that these improvement efforts are worth the time invested.
Top comments (4)
This is exactly how we are treating Tech Debt in my team.
I have managed several teams in several companies now, one common complain I often hear from developers is the burden of Tech Debt. It always goes in the lines of: we have too much debt, we are not allowed to fix it, we are expected to go full speed ahead with new work only.
In my new team I never hear such complains, why? because we empower the team to do what you just described. That's all it takes
In the end a lot of it is about trust between developers and stakeholders/managers. This visibility and process then helps create the required trust.
Glad to hear you found the same in your team!
I love the idea of the Wall of Technical Debt!
By the way, a very good approach on how to handle your tech debt!
Yeah I also thought it was a very cool idea! Another team in my company has now mapped and prioritized their technical debt on the wall, definitely seems like something worth experimenting with.