“Let’s release it now”. Peter Product Owner says.
“But Peter, we haven’t tested it yet. We don’t know if it works with all the other Increments, we don’t know if the user would accept it, we haven't even done the regression test.” the developers reply concerned.
“Well,” Peter answers, “I think it looks good and the stakeholders demand it, so I’m releasing it right away.”
After releasing it, the functionality itself worked. But under the hood, there was a lot more to do to really finish the Increment to meet quality standards. Technical Debt was introduced into the product. Technically, this team could go to production. Yet, due to the limited transparency from the outside, they were setting themselves up for a large amount of rework. They continued to release features on top of this untested part. What essentially is being built, is a house of cards. If the bottom one folds, the entire thing collapses and you have to redo everything.
That’s no different with technical debt. You could go to production. But is it a good idea? I don’t think so. Sometimes it makes sense to introduce technical debt. In situations where you want to learn really quickly to verify assumptions, for instance. Keep in mind that this debt needs to be repaid asap, and most likely with some interest, too. Time consumed to remove technical debt decreases the time you can spend on creating new valuable features.
Undone work, on the other hand, completely inhibits you from going to production. There is zero, or even potentially negative, value there. A negative value is what actually lowers the current value. For example, a shopping cart feature is added to a webshop. The entire back-end, middleware, etc. are in place, but the button itself is missing. That is undone work. It’s stopping you from going to production.
Technical Debt is everywhere
Let me give you a different example to paint the picture. The other day, my kids made a horrible mess in the kitchen. Cups were everywhere, drinks were spilled, plates were on the floor, and even the pans were not spared.
It was a terrible mess. I communicated my objective to my very junior developers: The kitchen must be cleared and cleaned so that usually living is enabled again and I don’t get mentally bothered every time I look at this chaos. Please be done when I come back from doing the laundry. “Ay ay, captain daddy!” I heard.
Photo by Jason Leung on Unsplash
So I came back from the laundry trenches, and indeed, everything looked clean. “Well done, kids!” As you may have read, the second to last sentence said looked clean. As I opened the cupboards, the plates, cups, and pans were just thrown in. It even had a damp towel from all the drinks that they wiped off the counter. Part was on me, obviously, as we didn’t discuss quality standards. But this is exactly what technical debt is. It looks nice on the outside, but scratching the surface reveals another mess.
Not only did they have to hear me complain, but they also had to interrupt their valuable tv-time to help me redo it. That’s paying back the tech debt, with interest. If it was cleared properly on the first go, they could have continued watching tv.
To stick with the kitchen and an example of undone work, would be that the sink would not have been installed. When the kitchen is delivered, you expect the sink to be there. Now you have a kitchen, but you also don’t. Think of undone work as really slow-speed internet. It’s better to not have it than to have it and it barely works.
Both have consequences
Ultimately it’s obviously better to prove both from happening. But technical debt could be an option to rapidly gather feedback and pay back the debt as soon as you can to limit future damage.
Undone work could not only deliver negative value for your customers, it could even damage your reputation. The effect of going to production with undone work can be catastrophic.
Ensure that quality is understood, and any tech debt is transparent. I once worked with a team that thought they had maybe four days worth of tech debt, for 2 developers to work on. When I organized a few refinement sessions just to discover our total amount of tech debt throughout the entire product (that was already in production for a few years), it appeared they had five full Sprints for the entire team to redo. Putting that into figures, they had wasted roughly half a million euros on poor choices and designs. It’s demotivating, and disrespectful towards your stakeholders as well.
How do you prevent your team from introducing tech debt?