There are various reasons why technical debt is allowed to build up and various reasons why technical debt isn't paid down. I have previously written about this and I won't go into that again. The point of this post is to briefly discuss a method for understanding what technical debt exists, making it visible and stopping it from getting any worse. So for the purposes of this post I'm going to assume that tech debt is a thing, there are things that exist that you can call tech debt on your product and that you want to tackle them.
The idea of a cost v value quadrant is far from new. I can't remember the context of when I was first introduced to them but I've certainly used them many times to help to priortise stuff in many different contexts. The basic idea is that you have a few things that you want to compare. Each of these comes with a cost and each of them has some kind of value. If you draw two axes, one representing value (I usually go low value on the left to high value on the right) the other representing cost (I usually go high cost on the bottom up to low cost at the top, or "hard to do" on the bottom up to "easy to do" at the top) then you have divided the area into "hard to do, low value" (bottom left), "easy to do, low value" (top left), "hard to do, high value" (bottom right) and "easy to do, high value" (top right). This whole idea is not dissimilar to the Eisenhower Decision Matrix.
It is important to note here that cost and value has been the most often used things for the two axes in one of these quadrants. However I have used other dimensions for such exercises. For example, if you have a sense that there are multiple dimensions that need to be considered when comparing a load of things, it might be helpful to first decide (maybe by using sliders) what the most important two dimensions are and then place all the stuff in a quadrant that only considers those two dimensions. This can potentially help to whittle down a large number of possible things to a smaller number before applying some other criteria in turn.
Why go from High Cost to Low Cost on the vertical Axis?
Many people that I have come across have asked me why I effectively put high cost on the bottom of the axis up to low cost at the top of the vertical axis. The answer is simple, I want to focus on stuff in the top right of the resulting quadrant. For some reason I have always found it pleasing to get to a state where we concentrate on things in the top right. That is just me though, if you want to go Low cost to High Cost, feel free. You'll just then concentrate on the bottom right quadrant in a cost v value comparison.
Tech Debt Discovery Workshop
I have seen many organisations handle tech debt badly. Some places are all too ready to create it, "we don't have time for gold plating, get the thing done and we'll fix it later" is a common attitude. Some other organisations create tech debt because their engineering practices are not mature enough, or their quality engineering function isn't strong enough, to understand or prevent tech debt accumulating, "what is a contract test?". The purpose of a tech debt discovery workshop is to socialise what tech debt is, in all the forms that we know that it exists in this organisation, surface all of the items that currently exist and get a basic idea of prioritisation for them.
Setting up the Workshop
The setup of the workshop is very simple. You need a whiteboard with a quadrant on it (as above), some people who know what tech debt items that need addressing, some stickies and some sharpies. Once you've done the setup, your whiteboard should look something like this (the worried looking client tech lead running his first ever workshop and the extraneous stuff on the whiteboard are optional):
If you zoom in closely you'll see that we drew two axes on the whiteboard behind the gentleman in the pink t-shirt. Whoever is facilitating the workshop needs to explain clearly to everybody what the goal of the workshop is (in this case, discover how much tech debt we have and get a feel for what we might tackle first), and explain what the quadrant on the whiteboard is.
Stage 1 - Crowdsource the Items
As with a lot of workshops, one of the goals of the workshop is to get everybody to think they contributed to the outcome and thus get buy-in from all of the people in the group for whatever outcomes you are going to arrive out. Crowdsourcing is a great way to do this. So give everybody a load of stickies and a sharpie and ask them to write down in each stickie something that they'd like to fix that they think is tech debt. They then stick all of their stickies on an appropriate point of the quadrant. It is important at this point to stress that they shouldn't take too much time getting the thing in exactly the right place. There will be time later for a group discussion and adjustments. In my example, after this first stage the board looked like this:
Not that it is far from uncommon in such a workshop for stuff to be grouped to the right of the vertical axis. It is pretty natural for people to only think about stuff that is valuable, hence only stick things on the "high value" side of the picture.
Stage 2 - Discuss, Group and Place Items
After everybody has thought of everything that they are going to think of the facilitator needs to go through every item in turn, make sure everybody understands what it means group it with any duplicates or similar items and position it somewhere sensibly. Note that this has to be an iterative process. We are not putting an absolute value or implementation cost on each item, rather we are interested in saying "is this more valuable than that?" or "is this harder to fix than that?". Also at this stage, the discussion may well prompt more things to get surfaced or some items to consolidate into larger items. If this happens, fine, add them as you go. At the end of this stage, you should have your final session output that looks something like this:
Again, the happy looking tech lead who has just successfully facilitated his first workshop is optional
The next steps will depend on the situation you are in. In the case of the workshop that we ran in which I took the photographs in this post, we had not yet put anything live in our product. We were delivering an internal PaaS offering. Our priority in the early part of the project was to get things ready for the internal teams to use but not necessarily production hardened (unless it would cause undue rework to do the two things separately) and thus we were counting a lot of as yet not done stuff as technical debt for the purposes of the workshop. As we knew that we weren't prepared to go to production without a lot of these items, we made stories out of all of them and prioritised the ones that were necessary for production hardening or that were otherwise high value according to the quadrant.
Keeping the Quadrant As a Project Artefact
As I alluded to at the start of this post, and as I have written about before, some organisations have a hard time getting to their technical debt items. An anti pattern I have often seen is when teams resolve, sometimes at the behest of a CTO or senior manager, to allocate a percentage of their sprint time to debt items. This is problematic in my experience for at least 3 reasons. Firstly, to put something in a sprint plan means it must exist in your card management system and thus you are paying an inventory management tax. Secondly your devs will likely (though not always) want to work on something new rather than something seen as a boring maintenance task. Thirdly, as soon as your team comes under pressure to get all the things done in the sprint that they "committed" to, the debt items are the scope that gets cut. The last of the three is the most dangerous and that type of attitude is probably one of the major reasons why you have a load of debt to deal with. I covered this in the technical debt cycle in an earlier post.
So my favourite way to keep on top of technical debt is to keep the quadrant as part of the product wall. Every time you knowingly create more tech debt, or you discover some tech debt, write out a new debt card and stick it on the wall. Then every day at stand up or tech huddle or whatever, discuss this new thing, get agreement from the whole team that it is a thing and also where it should live in the quadrant. Adding things to the wall should come to be something that people just don't want to do or at least do reluctantly.
Tackling the Debt Wall
Hopefully the stuff on the wall is small stuff, like add one test or refactor one thing. I have had great success in various teams by doing "debt days". Either one day a week, or maybe one afternoon, everybody drops the thing they are working on and picks something off the wall. Either they pair with another developer to learn something new or just to share context or they do something really simple on their own because they think it will be fun or maybe because the thing is something that is causing them some personal pain. It doesn't matter. The outcome will either be that the thing is fixed, or if it turns out to be too complex, maybe there could be a story to play or a spike to consider or a discussion to have. In any case, everybody has a fun time, hopefully, and the debt pile is reduced.