Martin Fowler's Technical Debt Quandrant
Ages ago I blogged about The Technical Debt Quadrant as explained by Martin Fowler in his blog from some years earlier. When I re-read that article (Martin's, not mine) it looks a lot like a discussion that was of its time. The reason why I raise this again is because recently I came across a completely different kind of debt quadrant, not for helping us understand how it came to be but for helping us to understand when to pay it back. In the course of some discussions with my current client I combined it with a thing that I learned from my previous client to come up with a plan to address technical debt.Bug Squash
At my last client I was tech lead of a team that was mainly responsible for fixing production defects in the platform that we were implementing. Leaving aside whether this is an anti-pattern (it is) we were managing a large backlog of defects whilst simultaneously adding "BAU" enhancements to the platform itself. One of the side effects of this dual focus was that annoying little defects rarely got fixed. A knock on effect of that was that our backlog was growing, we were spending money managing it but we didn't really know if the backlog was real or not.
A Bug Bash is an exercise to be done occasionally, the object of which is to find previously undiscovered, or unrecorded, issues and get them on somebody's backlog. This could be semi regular, just before a major release or upgrade or just a fun afternoon. In my experience of these occasions, anybody can take part, there is probably some kind of refreshments offered and there may be some kind of gamification and prizes on offer.
Somebody in the team proposed something that came to be known as "Bug Squash". It wasn't me, for sure, but I remember thinking it was a great idea and that we should try it. The idea is kind of the opposite of a Bug Bash. We decided that every Wednesday afternoon we would all drop everything that we were working on and we'd look at the backlog from the least important stuff upwards (instead of the usual top down way of picking stuff to fix) and we would either fix the issue straight into the code base or we would record in the ticket why it was no longer an issue and close the ticket. We left it up to everybody to decide exactly how they wanted to work. If they wanted to pair fine, if they didn't that was also fine. This had some great benefits. First, it was fun. Second, our backlog got smaller so we could all share in the success of that, third it spread context of the whole codebase amongst more people.
Another Tech Debt Quandrant
My current client thinks it has a lot of tech debt and this is one of the reasons why myself and a colleague are here for about 3 months to try and advise on some thing they can do to help themselves. As you might expect, tech debt is a symptom of some wider problems with the organisation. Unlike many symptoms though, it is always worth treating tech debt because it has a nasty habit of multiplying and making your future life more difficult.
One of the big problems is that the tech debt makes it hard to do stuff. So they know they need to be paying this debt down but they find it hard to find the time to pay it down. And one thing that makes it hard to find time to pay down tech debt is tech debt. I think everybody can see where that one ends. We've tried a few different things to help with the situation. Currently each team is asked to assign 20% (it might be 10%) of their capacity in their sprint plan to debt items. The trouble is that these are the very items that feel the axe if the teams realise that they won't make their sprint commitment. Moreover, somebody spent some time analysing the debt, creating a card, putting on the board, bringing it into the sprint cycle etc etc. So the management of the problem becomes part of the problem itself (see my earlier post on inventory management).
So in advising on a way to get to the outcome (reduced technical debt) what we needed was a method that was easy to manage and track that encouraged people to pay down the debt. The first stage was a debt quadrant (an idea that was introduced to me by a ThoughtWorks colleague last year). Instead of just having a debt wall onto which everybody pins things they'd like to fix, you split your debt wall into 4 quadrants, as per the picture below.
For those that can't read my handwriting (probably everybody) the vertical axis is labelled "Ease of Solution" and the horizontal axis is labelled "Impact". So I hope it is therefore obvious that stuff in the top right (high impact, easy to fix) should be fixed as soon as possible. The stuff in the top left should be looked at and maybe fixed, the stuff in the bottom right should be looked at, analysed and prioritised into the normal process (whatever that is). Hopefully then, this simple visualisation gives each team a good way to record, manage and pay down their tech debt.
Debt Days
But what if people still don't feel like they have the time to do any of this? Our simple suggestion was that one afternoon a week (that would be about 10% so one whole day or two half days would be 20%) the team should drop everything they are doing on the sprint. Instead, they should pick up one of the cards in the top right of the debt quadrant and do something about it. No time used on planning or estimation or arguing what is the most important thing. Just pay back some tech debt.
It is early days yet but by combining the ideas of a simple quadrant and setting aside REAL time to do something (not time in a sprint plan that might not happen) we will hopefully get some significant payback of our debt pile whilst having some fun along the way.