Managing your Technical Debt
Plan your debt, don’t let it creep up on you. You may find it is your new best friend when delivering at pace.
Like monetary debt, technical debt should be planned and managed. Planning technical debt can give rise to greater agility and speed up delivery. This can be done with a fairly simple re-framing of what technical debt is, and a bit of good old communication.
TLDR; Sometimes, you just don’t know exactly what work you need to do to deliver something, especially if working on a legacy or unfamiliar platform. However, you should definitely know the general types of work — such as unit testing, refactoring, improving efficiency, automation testing, removing old code, security improvements etc etc — as these should be a part of the Definition of Done. In which case you can call some of that out as a candidate for planned Technical Debt. Planned Debt is easier to manage, as you can put structures in place to ensure it is repaid.
The Definition of Done (DoD) allows us to define a quality standard that we work to, and help us when planning the work that is required to deliver something (or some value). However, when we get our heads down and really get into the work we often find we must make compromises: either protract our delivery timeline, reduce scope, reduce the quality of the work we deliver, or (and quite probably) a combination of all three.
When I say quality, I am referring to all the many facets that make truly great software— such as functional, readable, reliable, secure, lean, and performant code, with good architecture, test coverage, and documentation.
Engineering teams very often regard the idea of sacrificing quality in order to meet deadlines as heresy and would rather see the scope adjusted before. Meanwhile other teams (sales, product, finance) — who perhaps cannot quantify the value of this quality or have priorities elsewhere — very often apply pressure to onto the engineering team delivery the full scope on time.
So, often the situation arises that our Definition of Done is an artefact designed by the engineers, for the engineers, but which works in conflict with other business needs.
Planned Technical Debt
The concept of planned debt takes the idea of technical debt a step further.
Typically, technical debt occurs when a bit of code fails to meet the desired quality standard. This is either found in existing code or caused when shortcuts must be made during delivery.
Perhaps the simplest way to describe the purpose of Agile is to deliver the most valuable stuff as early as possible. Usually when we talk about this, we assume that what is implied here is to deliver the critical functionality before the non-critical. So, we must ask ourselves “what functionality can we live without?” when we prioritise out backlog.
Planned technical debt simply asks the question “what work can we live without?” during the planning stage (e.g. sprint planning, backlog refinement, or even earlier). Identifying candidates for technical debt very early means that they can be prioritised in the backlog early as well.
Planned or not, technical debt is a type of work, and therefore should be reflected on your backlog. Check out my article on the various backlog item types.
These new technical debt backlog items can be individually estimated and the value of them can be discretely understood. This means they can be budgeted for and prioritised for delivery in the future. This is addresses one of the key pain points for engineers, concerned that the problems they are storing up will never see the light of day again.
Doing this well does of course require discipline. Ensuring that this works is not just the responsibility of the engineering teams. They are responsible for understanding the business objectives and sensibly excluding non-critical work. They are responsible for explaining and capturing the risks introduced.
However, the wider business (those teams mentioned above), must take responsibility for understanding the risks raised, prioritising the debt backlog items appropriately, and ensuring that there is time and budget to pick them up. This is absolutely critical. As with so many facets of highly effective software delivery, success is the responsibility of almost every area of the business.
Set Your Bar
On paper, the Definition of Done may set a very high bar. Indeed, it really should.
However, as a team you can set your expectation such that you can tolerate a lower bar. E.g. “so long as a piece of work is, 80% of Done, and the remaining 20% is captured as planned technical debt, it is good enough”.
You can decide which items from your DoD are critical, you could rank the value of each component, or you can simply agree to make this a discussion point during planning and agree what good enough is based on the business value of the thing being delivered.
Either way, you should agree (or align) on what your measure for good enough is. This decision should be made in consultation with those other business areas that apply that familiar pressure, and in that consultation you will want to negotiate over the allocation of time/budget to address that debt in the future.
Tips:
Adding the rule “all technical debt is added to the backlog” to you DoD could help remind the team to do this as they proceed.
If you have a Definition of Ready, then maybe adding a checkpoint to ensure you plan your debt would be helpful too!
Now you have a Definition of Done that aligns with the objectives of the organisation, and that can be supported both the engineers and the non-technical stakeholders, and — so importantly — an agreed repayment plan.
Summary
Some teams think of tech debt as something they come across when doing something else; a gremlin in the code that means more time is needed to complete the job at hand.
Some teams are calling out new work as potential tech debt, and some of those teams are even managing it and putting it in a backlog.
However, very few teams, it would seem, proactively create a mechanisms for identifying technical debt up front — perhaps akin taking out a low interest loan rather than a payday loan. And fewer still appear to have tools in place to peruse that debt in the future.
In some environments this may never come up, but in others — perhaps where getting value in front of users as fast as possible is mission critical — it will be very obvious frameworks like this are of benefit.
I’d love to hear your thoughts and have your feedback. What is your experience with managing (or not managing) technical debt? Please applaud, share, and comment!