A DEEPER UNDERSTANDING OF…

Technical Debt

Road to Mastery — Season 2 — Episode 4

Time to talk about the big evil monster in our Product Development universe. Is it our Cthulhu, Morgoth, Chimera, Frankenstein? Or is it the Grim Reaper that will one day come knocking on the doors of every product made. Or perhaps it’s the “Hecatoncheires” who were:

“not only known for their frightful enormity, but also for their ghastly arrangement of hundred arms and fifty heads. Even Uranus was so taken back by their ugliness that he decided to push them back into their mother’s womb. On failing to do so, they were subsequently banished to the underworld […]” — Hecatoncheires

Our creature of dread indeed. It’s time to talk about ‘the one that shall not be named’ and isn’t even mentioned in the Scrum Guide. No, I am not talking about the Project Manager. For the sake of this story we’ll refer to ‘it’ as:

“Technical Debt: the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.” — Scrum.org Developer Glossary

Or in any of these preferable definitions:

• It’s the creature that breeds in an unpredictable swamp of unmaintainable mess…
• It’s the thing developers attribute to someone or something else; like all that expired stuff rotting in the fridge at student-dorms, growing a life of its own and no-one bothers to throw away because ‘it’s not theirs’.
• It’s such a mysterious, complex, out-worldly monstrosity, it could make for a thrilling X-files episode.
• It’s the stuff developers ignore but inevitably comes back to haunt them in unpredictable apocalyptic ways.
• It’s when developers meet cross-habitat, they compare sizes.
• It’s unleashed after a deadline long struck, yet coders press on. Like a defeated, demoralized, and exhausted army, coders stumble after crack-whipped death-marches, knowing that not everyone will make it…
• It’s Freddy’s Nightmare developers never wake up from.
• It’s Jack’s Raging Bile Duct.

And I wish I was joking.

Today’s decisions…

Technical Debt: face its dread today? or its calamity tomorrow? Technical Debt is attributed to poor design, architecture, or managerial decisions. Yet it’s bigger than all those who contributed to the product. When the product lives in a complex and volatile market, Technical Debt contains ‘unknown unknowns’ (scary huh) and continues to emerge even when the product isn’t. And that makes it so hard to take collective ownership over it… as not a single person involved can neither predict, understand nor grasp it completely.

The trouble with Technical Debt is that, as it grows, it obscures. It’s the nemesis of Transparency. It results in a scattered and distorted view and results in poorer decisions and the draining of value. For example, something might look like a cute little update, but the tweak might reveal a dependency nightmare.

We also base decisions based on past performance:

“Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide

So, in a ‘greenfield project’ teams can deliver fast. Woooosh! Wow! But as the Product grows larger and complexity increases, they will slow down. The speed at which the team is moving at the start sets expectations for ‘forward-looking decision making’. Add to that the common expectation that, with Scrum, their velocity should increase (as Jeff Sutherland famously put it: “twice the work in half the time”), we face somewhat of a conundrum. So what do developers to live up to this expectation? dot dot dot.

4 ways to manage ‘it’…

As a Product Owner, given that one ‘owns’ the Product, one also owns its accumulated debt and its total cost of ownership (which increases as Technical Debt builds up). But managing it is a collective team exercise.

If only there was something like a Ghost Buster contraption that teams could apply to suck in and contain all those malicious spirits.

Managing Technical Debt is one of the hardest challenges for a Scrum Team to overcome. So here are some pointers.

1- Make it visible.

As with any horror movie, as soon as the monster is shown visually, it becomes way less scary. And so it is with Technical Debt. By visibility, I do imply it’s best for it to be in everyone’s face on the work floor. This way no one can ignore it. But where and how to visualize? The Product Backlog?

“The Product Backlog is an ordered list of everything that is known to be needed in the product.” — The Scrum Guide [emphasis added]

Well, Technical Debt isn’t technically ‘needed’. We’re rather rid of it after all. But one could argue the reverse too. Technical Debt requires changes to the product. These changes are needed. Now… there is a lot of back and forth about whether or not it should be part of the Backlog. Some will argue it is the burden of the Development Team as it is technical in nature. How could the Product Owner possibly manage this? one might argue. Alternatively one might argue it’s a value trade-off; it’s debt after all.

2- Refactor continuously

Technical Debt is never not there, and should not be never worked on. Tricky line huh. But teams that understand this can ‘tame’ or ‘domesticate’ it.

It’s there every day and a normal part of the day and needs continuous attention. One could even go as far as seeing it needs love and caring. Unfortunately, I have yet to meet a Product Owner or Developer demonstrating love and care for Technical Debt…

In any case, what I personally suggest NOT TO DO is calling in something like ‘Refactor Sprints’ or ‘Hardening Sprints’. Those definitions are paradoxical in their naming and reek like Waterfall phases/stages. Not that it’s a bad practice persé, but it implies its the Sprint’s purpose to pay-off accumulated debt in batches that get in the way of value delivery. This is not how contributors to Scrum intended Sprints to be (ab)used.

In my own experience this principle can work well as a strategy in dealing with Technical Debt: For time spend on developing something new, spend equal time refactoring something old. A simple, but powerful refactoring principle. I know, it’s too easy to be this principled in writing advice. But looking and turning back frequently when advancing is a grand approach to developing products in complex environments.

But this is something a professional developer shouldn’t ask permission for and just @!#$ do it! If you are a developer and reading this: if you’re a professional, you produce technical quality, not a technical mess. If you think being a professional is about writing fast, think again. It’s about taking the time to make it right… and only then learning how to do that at speed.

Another discipline to follow is one known to boy-scouts: “always leave the campground cleaner than how you found it”. This is called the Boy Scout Rule and this also applies to whatever it is you are developing.

So professional Scrum Developers learn to create their own steady routine and habits. They themselves optimize this routine as Scrum promotes self-organization. But here is an example that can be used as inspiration to discuss and try that works well with the Pomodoro technique.

3- Definitions of “Done”

Let me post a “Beware of Invisible Scrum Cows” sign right here.

Beware of Definitions of “Done” (DoD’s) that define an increment that isn’t quite “done”. Yeah, that sounds puzzling I know. But, no joke, I’ve worked with teams where their DoD’s only got them as far as ‘ready for review’ or ‘being published to a staging or testing environment’. If this is the case with your team: they are dumping, not delivering.

Also, beware that when adding or changing DoD’s they will impact the entire Increment. It will require the Increment to be reworked to meet its new standard. That said, although this may sound daunting, it shouldn’t hold the team back. The DoD’s are part of the fundamental strategy of managing Technical Debt. As Scrum Teams mature, they will introduce more stringent DoD’s. This is essential to counter Technical Debt.

4- Remove stuff

We’ll the easiest way to manage Technical Debt is, well… by not adding to it in the first place. There is profound wisdom in the Agile Manifesto:

“Simplicity — the art of maximizing the amount of work not done — is essential.” — The Agile Manifesto

I am not saying this to be lame. Many seasoned developers will agree that they’ve worked on lots of stuff that ended up not being all that useful (or used at all). All that useless stuff adds to the product’s complexity. It pays to learn early what deliveries are really adding value and which aren’t. If the team is able to pick up on it fast, it might be able to take it out with relative ease; the longer it exists within the product, the harder it will likely be to remove it.

This is yet another psychological barrier to break. After all, no one really enjoys throwing stuff away after a lot of energy has gone into it. It feels like a waste. But face it… keeping the waste in the product wastes the product.

Tomorrow’s changes…

I already both long for and yet dread the day the next update of the Scrum Guide is published. For me, it means many articles in this series will have to be revisited. But even the Scrum Framework itself is battling its own debt. There are so many outdated notions and misconceptions over it… and with each update, for all its intents and purposes, will add even more to it.

I hope you enjoyed this episode and will share your thoughts on Technical Debt in the comments or over at Slack.

To end with a TL;DR: Don’t ignore it. Embrace it.

The Road to PSM III is being reformatted to The Road to Mastery! Part I: Down the Rabbit Hole is now available.

Up next: