Technical Debt: 3 ways to articulate and get buy-in from “that person”

The decision of removing technical debt can be crucial and is often a grey area. In some cases, to increase the speed of delivery, we have to carry the debt as long as we have control over it. When shit gets real and everything is slowly getting out of hands, we need to repay this debt by investing time and effort in, say refactoring. But it can be a hassle to carry out when we need it the most; not because we hate it but because we never get buy-in from “that person” who doesn’t think it’s important.


In self managed teams it may not be an issue but other teams may have faced a discussion at least once around this in their lifetime. “Refactoring doesn’t provide any value to the end user” – most common reply when we try to prioritise housekeeping. In several cases the person standing in your way is non-technical or have limited knowledge of the architecture which needs this debt removed asap. At this moment we have to open up bravely and explain “that person” why we need it happen, now. Here are 3 analogies that I use often to articulate the situation and get the buy-in.

Swim back to Shore Alive

I came up with this after watching Gattaca (**spoiler alert**) where two brothers compete to swim as far as they can, far from the shore. In the climax, Vincent was willing to die to beat his brother Anton, to prove to himself that his dream is larger than his own life.


Anyway, as a regular swimmer the hardest part of challenging yourself is to know your true capability and stamina. Just because you have stamina to swim 1 mile at one go, you don’t attempt to swim 1 mile inside the sea. You go 500m in and pivot so that you can use the other 500m capacity to come back to the shore, alive. You repeat this thousand times to increase your stamina and never ever lie about it. Lying to yourself and being overconfident will kill you. You will be fooling no one but yourself.

Now, apply this analogy to technical debt where the distance and capability is comparable to the threshold of debt we can carry at a given time. Within a team it should be non-negotiable, we shouldn’t keep building technical debt because someone have promised a deadline to launch, without asking us. You can try going that extra mile to deliver more ignoring this technical debt but sooner than later you will be screwed big time, your software will not be scalable anymore. You will have no choice but to stop everything and start from scratch. Stop early to analyse and always keep a recovery plan.

The Boiling Frog

This analogy is out there for a while (Source – 1, 2), although not used often in reference to technical debt (except the linked articles). Here’s how the story goes.

Researchers found that when they put a frog in a pan of boiling water, the instant reaction from the frog is to jump out asap. Because it’s sudden, it changes the environment within fraction of seconds and the pain is unbearable (I guess).

On the other hand, when they put a frog in cold water and put the water to boil over time, the frog just boiled to death. This time the change in temperature was so gradual that the frog does not realise it’s boiling to death.

When our business is hit by a sudden change and we see it going out of hand, we react quickly. If a continuous integration run fails blocking everyone from using the code base without rebuilding it, we have to fix it right away. Therefore, we act asap and jump out of the problem right away. In case of technical debt, it is slow and gradual, a death threat on the rise. It’s so subtle to begin with that no one cares (we may not even know). We eventually find it out and choose to delay the necessary changes. At one point it becomes so bad, we cannot recover anymore. Before we realise that the threshold of acceptance has crossed far back, we are already in deep trouble.

Financial Debt

The most widely used analogy around technical debt is simply comparing it with financial debt.

Assume you got a new credit card with a 40% APR. Your card limit is £1200 and you get a month interest free usage. As long as you borrowed money and paid within that 1 month window, you pay nothing on interest. Even if you go above the duration and keep paying a minimum about back every month it is within your control. The moment you stop paying anything after borrowing, you are screwed as the Capital plus the interest becomes your new capital which adds more interest and your loose the control.

Technical debt is exactly that. If you have to borrow debt to go fast and deliver an extremely important feature, by all means do it. Just make sure you keep a track of the debt you are creating by not maintaining the code regularly. Loose coupling is fine and still scalable. The moment we start writing hard coded software and tightly coupled features, we slowly increase the debt to never pay it back fully without loosing everything and starting from scratch. Pay the minimal debt back when you can and make it a habit, a practice. Don’t let the debt ruin your business.

End Note

Be true to yourself and leave the decision of controlling the technical debt to the community who knows best, the developers. We are not working in the code base daily, they do. Trust their instinct. If you are a big fan of velocity like me, let them estimate keeping refactoring in mind. The team shouldn’t entertain “that person” who always ask a silly question like “can’t we wait till the next month?”. On the contrary, if they have a business strategy to back it up with data, don’t ignore it either. We just have to know what we are capable of supporting and stop lying to ourselves.

Hope this helps. If you have few more ways, feel free to share the ideas/analogies !


Velocity – a fallacy often blamed on Scrum

Overheard someone saying the other day – “Point based estimation is still a pointless metric and so is the velocity calculation in Scrum”. Yes I strongly disagree, not because I believe in the fallacy called velocity but because it has nothing to do with Scrum or being agile. Scrum is not a silver bullet, agree, but that comment clearly indicates a misguided anti-pattern. I am not a Scrum fanatic unless I wouldn’t create XDE, but this concerns every Agilist out there. It is about the trend of misinterpretation and the habit of many professionals to modify an immutable framework.

Scrum being a framework (not describing a method or practice) is being misinterpreted by many even after it’s 20 years of existence. While many organisations are still learning and implementing Scrum, we see more and more discussion around “Velocity” and “Point based estimation” which is not even part of Scrum in the first place (no mention in Scrum Guide).

Capacity is what we should focus on, not Velocity.

Velocity calculation is a result of the point based estimation techniques, which are also misused as a performance metric. Ask an average Scrum team how they measure team performance, the first word will be Velocity. Be it linear or relative estimation, when we use a number for anything, our beautiful minds translates it to an “absolute value” which is not negotiable. We start writing it in a card or add it on a tool to track velocity. Then we slowly & voluntarily dive into deeper political horizon of team velocity comparisons, false sense of predictability to never come back out again.

Intention of point based estimation is to break the ice.

Technical experts are usually shy, they love to just to get it done, write the code or test while listening to their favourite music. Estimation sessions gives them an opportunity to open up and be valued for their knowledge. They agree or disagree or share a fact that no one thought about before, to establish a shared understanding. Then they leave the room to start working on it but never leave the number behind. It stays in the card/tool and makes them uncomfortable when they find out a hidden issue which will screw the estimated number. This is frightening, as it becomes a matter of their honour and a measure of their knowledge, which makes them look retarded in front of their team.

“We said it’s 5 but now it seems like a 13, WTF ! If I tell the team they will think I am stupid.” – This, we can live without. This stops us from being brave and fail fast as failure is not an option. To be agile we need to embrace failure as learning opportunities. This negative Hawthorne effect goes against agility and get blamed on Scrum because of the time boxed sprints where velocity really applies.

We “estimated” the avg. velocity as 40 but it somehow becomes a “promise” to stakeholders which is not open for negotiation in many cases.

It creates an obsession among us to match the velocity every time or more to show off. Truth is, Velocity can easily be manipulated and somehow the “people” aspect get thrown out the window. Where is the trust? Where is the working software? That’s why, even though the point based estimations and velocity calculation were created to “guide” us, as human beings we cannot trust ourselves on showing our true nature – urge to control the uncontrollable. Therefore, to become agile we have to let go of this metric from Scrum, for good. We don’t want to be that person who focuses on these numbers and not outcomes.

Let’s get back to the basics of Agility

  • The fact is, we try to measure the scope in units like time, but we can’t. That doesn’t mean we have to use numbers. Be creative and find another way which doesn’t promote false sense of control over the development cycle. It’s development not manufacturing, you will fail many times before finding the right product. Scrum is for development not manufacturing.
  • RTFM – there is a reason Scrum has a guide so stop associating Velocity and Estimates as a “mandatory” Scrum metric while implementing. You are digging your own grave by doing so.
  • Stop asking Scrum Masters to report velocity as a metric. Even if they are in place, they are private to the teams, not open for all.
  • If you can’t negotiate, you are NOT agile. You might as well do Waterfall, it will give you the same results.
  • Stop making “Promises” on deadlines using velocity. If a person have never worked hands on in a code base, their knowledge about the product is at best worthless. If that person is making promises by predicting velocity, the joke is on them.

End Note

Velocity is a fallacy, whether you like it or not. Use it only if you are still winning. If you are failing then please let it go, just don’t blame it on Scrum. Scrum is much powerful without it.


Definition of Done (DoD) in XDE Framework

In my last post about Definition of Done (DoD) – The Holy Cow Approach, we have seen how “Done” can be misinterpreted just because there is no set definition for everyone. We have ways to deal with DoD by agreeing together what is Done before starting work on a User Story or any form of backlog item. This definition therefore can change depending on context, product, team or even client demand.

What if we don’t have to go through this never ending debate of defining a done for each work item? The internet if full of these discussion, agreement and disagreements which we can live without.

What if, we have a universal DoD which establishes shared understanding company wide?

Definition of Done (DoD) in XDE is a shared understanding

Xtreme Decoupled Engineering (XDE) has a beautiful way of replacing this small talk with something that adds real value – Delivery and End user feedback. In XDE, we don’t need to establish a ground rule about where to stop, before starting a work. We stop and call it Done when we get “a” user feedback – good, bad or neutral. If it’s good we celebrate, if bad we learn and if neutral we let the Product Expert decide where to go from there.

If this is not Simplicity, what is?


The One Rule in XDE makes sure we do not get distracted and the Delivery Expert being the Servant Leader of the 1R Team guides the bubble to focus on one work at a time. DoD is therefore universal to all teams and anyone interested to know the ETA of a certain value, don’t have to worry about what “state” it is coming out. It will always come out in a “Ready to Ship” state whenever it is done and wherever it is deployed for the feedback.

DoD in XDE invokes the boundary for Cycle Time measurement

Cycle time is the total time from the start to the end of the development process, which increases predictability especially if we are part of a Service Level Agreement (SLA). DoD in XDE takes help from the One Rule to establish these SLAs with predictable data over time to create a healthy metric to optimise the process. Here’s a visual which summarises how it work:

As we can see, the Cycle time is basically the duration which a 1R team takes to achieve the DoD following One Rule. It also promotes implementation of DevOps by an extreme reduction of multitasking and focusing on the end user feedback.


We have a tendency of making things complicated when there is a simpler solution. XDE’s definition of Done simplifies this ambiguous topic of discussion. An organisation can worry about bigger things which needs attention and teams can work towards the same goal every time like a second nature.

More about XDE: