Winging It: Going Live with Technical Debt

Every day across the world a Sprint ends somewhere. Every day, a team reviews what has been done, and what has not been done. And every day, a team will fudge the two and push undone work through to live. So every day, somewhere in the world Scrum gets broken. Whilst an angel may not exactly cry, this knowledge makes me angry and disappointed. Rework will be needed and probably at a greater cost than if things were completed properly in the first place. Undercutting a Definition of Done is like having a badly set arm in plaster - you'll just have to break it again and reset it. If this happens to a team I'm mentoring, I'll make sure they complete their undone work before any new commitments are allowed to start. In other words, I'll make sure they understand the pain of fudging things as quickly as I can break their arms and reset them. "This hurts me more than it does you", I'll say with a grin...but then I'm an agile coach, not an angel.

This undone work has a name. It's called "technical debt". I love technical debt...the expression, that is. It gets over the idea of borrowing from the future. Ward Cunningham first wrote about technical debt back in 1992, though it would be another ten years before the expression itself started to take root. I remember a time when there was no name for this concept. I remember it as a time when cowboy coders were able to hide behind the newly raised agile banner and throw their junk over the wall. They built up hellish problems for other people, but by then they had moved on to other companies or projects, surfing the wave of their own incompetence, always dodging that last roller before it came crashing down. Now we have a name for the problems they cause...Technical Debt. Once a thing is named it can be controlled. As a result the cowboys are left with fewer places to hide. This is great stuff. It makes me very happy. In fact I feel so strongly about it I'm going to highlight this next point in bold: the acknowledgment of Technical Debt represents the greatest advance in agile practice since the Manifesto.

Before we go any further, let's consider in more detail what technical debt actually is. I've already presented it as "undone work", but that encapsulates a range of problems. Let's consider the most obvious one first. Does the borrower have any intention of paying the debt back at all?

Debt versus embezzlement

You see, most of the technical debt that I have encountered isn't really what I'd call debt. It's more a case of technical embezzlement. When a cowboy delivers junk code and moves on, he's effectively stiffed the client but kept his pay. The client is left holding the broken product and the bill for repair. Usually the employer will have no effective recourse if work was accepted and the need for rework only became apparent later. The cowboy has simply indebted a product owner as the consequence of certain duties he was paid to perform. Even though I reckon it's a hustle, I can't argue against the principle of caveat emptor. So technical debt it is then.

Now let's look at honest technical debt. For debt to be honest, there must be an acknowledgement by all affected parties that it is being incurred in the first place. If the stakeholders know and accept this, then a plan can be put in place for paying the debt back. It might very well be a ticking time-bomb, but at least it is out in the open and the clock is visible. There may be no need to take action for the moment if there are bigger fish to fry. Technical debt isn't necessarily bad. It's like any other form of debt. It might genuinely be worth it. There'll be interest to pay of course - that badly set arm will need to be twisted - but perhaps the pain is acceptable if there are more important and urgent matters to take care of.

Is there a particular sort of debt that lends itself to honest treatment? Well, a common source is architectural refactoring. Significant design decisions can need rethinking as a system evolves, especially if they turn out not to be scalable. The architecture that was "just sufficient" in the early days starts creaking as the weight of responsibilities placed upon it increases. Gradually and almost imperceptably it ceases to be fit for purpose. This is nobody's fault and everybody's fault. In theory the situation should have been managed by aggressive and continuous refactoring, but in practice teams may have been encouraged - by their paying customer - to value delivery more. Perhaps an entire sprint will be needed to pay back this debt to the product architecture, and the team will need to convince the Product Owner that it is necessary and worthwhile. Clearly this isn't a good situation, but at least it's an honest one. Everyone knows about the problem. The customer is informed about their level of technical debt, and encouraged to make a decision about it. No-one sneaks away leaving a sucker to hold the bag. Honest debt isn't hidden.

So then, having technical debt isn't necessarily bad. It all depends upon specific circumstances and whether or not you are in a position to pay it off in a responsible fashion. This leads us inexorably to the next question. 

Can you actually release software that contains bugs and known issues?

If you've been paying attention so far, you can probably guess what the answer is. But let's ask the same question another way. Is it better to release a buggy product or no product at all?

Now, there is no shortage of CEOs and other suits who talk big about becoming "a zero defect organization", "no excuse for imperfection", and Six Sigma. They may even be astute enough to couch their rhetoric in terms of a Lean Value Stream and agile practice in general. Of course, these same suits will also squeeze resources and timescales so that compromises have to be made by people in the trenches, and technical debt ends up being incurred. Fortunately, agile practice does provide a remedy for this. The greatest imperative is to ship product and elicit feedback. So yes, you can actually release software that contains bugs and known issues. Of course we should aspire to "zero defects", but that's the end point of a journey that requires extensive organizational alignment. It isn't a starting point. What we need in the first instance is transparency - the honesty I talked about earlier - so we can see how and where technical debt is being incurred...and why. If you don't have an honest conversation about technical debt, you're just winging it with a compromised product. And I'll be looking for more broken arms to reset.

Oh, and before I forget...

It'll hurt me far more than it hurts you.