Managing Technical Debts - A Practical Approach pt. 1
And why we shouldn't neglect them!
There is no way for a digital product or service in use to not have technical debt. We could argue about what a technical debt is, but my general concept is anything preventing the end user to have the desired experience from a feature. You should use metrics to measure what is the desired experience you aim for your user.
That said, let’s suppose we already know some changes we should do to improve our product. So how could we prioritize them - knowing that we have way more new things to bring to life? The executives want the new, so they could sell and bring more profits to the company. There’s no way they’ll agree to prioritize technical debt, right? If that’s so, as product managers we have to change their mentality a bit - not entirely, because that’s impossible, trust me.
With my team in PicPay we currently work with the Lean Kanban method, in which we practice continuous delivery. In other words: a feature or evolution of the product goes into production, as soon as it passes through all the stages of the framework. I’m only saying that to give you context, because what I’ll say below is valid for any agile approach you choose.
We have two scopes to work with - we could call them tracks, too - in our workflow: OKRs and Support.
OKRs
These are activities aimed at achieving our Objectives and Key Results defined for the current Quarter. These activities are typically derived from the Epics → User Stories → Tasks structure.
Support
It is a rotating role (weekly), in which one person on the team is dedicated to answering questions arising from our slack’s support channel, incident analysis and other specific questions. And here is where we prioritize technical debts. We affectionately call these activitie housekeeping.
Dealing with technical debt is similar to maintaining a home. While you live in it, you have small, minimal tasks to maintain basic living conditions - now is the time to look at that pile of clothes waiting for the washing machine. If you neglect these minimal tasks, in the future they will become much bigger problems, perhaps even beyond the possibility of solution. The analogy is valid for our products and technical debts.
The main purpose of having two tracks, is to ensure that those doing OKR tasks don’t need to stop to focus on something else. There are quite some studies proving that when we change context, it greatly affects our productivity. But more than that, we must ensure we are progressing with our previously established objectives.
Meanwhile, we shouldn’t focus all our efforts pursuing OKRs, because there will have unexpected support activities and we must ensure someone is there to take them. But as I’ve mentioned, these activities are supposed to be unexpected - that means whoever is in this role will have idle time to do something else. And that’s when this person can pull a housekeeping task.
Avoiding spending too much time and resources on support tasks can be a challenge. It’s a good topic for another tale.
Housekeeping has a backlog of it’s own and everyone on the team can propose something about it. We should ask some questions first:
Could someone solve the problem in a few days at most?
The ideal should be within a day.
How big is the impact of this change for users?
We shouldn’t change user experience with this type of activity.
Which metric this change can affect?
Your team shouldn’t do househeeking at will. We want to do something based on a premise. If we keep tabs on performance, engineering and observability metrics, certainly we’ll find a purpose.
A small matrix like this could do the trick for us.
Keep in mind that effort is something everyone your team must agree on.
My pt. 2 post will bring metrics that can help us define and pursue housekeeping activities. More importantly, they are a good way to help us with the storytelling on why we are spending time with them.
Was it helpful for you? Let’s chat :)
References
https://asana.com/resources/context-switching