All organisations want to accelerate their time to market. The smart ones realise that attention to quality pays off in the long term, but many, for various reasons have a degree of technical debt. And it slows them down. It’s like they are saddled with a high-interest rate credit card and missing payments compound the interest!
So what is technical debt? It’s a frequently asked question and the answer is not entirely clear to everyone.
debt [dɛt] - an obligation to pay or do something, - a legal agreement specifying a payment or action and the penalty for failure to comply
Translate that into software terms...
What are the symptoms?
Cost too high, time to market too long
internal customer satisfaction needs improvement
De-motivation as everything is too difficult!
Do you recognise it now?
Key questions?
How high is your organisation's technical debt?
How does it impact your people and your business?
How much can you afford?
There is no credit limit on technical debt. Unless a team is refactoring on an ongoing basis, technical debt tends to grow over time as the underlying software decays.
It’s not always appropriate to refactor all of your legacy code, but it’s important to recognise when the same areas of the code cause repeat problems. Support data and problems with estimation vs actuals are great places to start.
What are the causes?
Deferred investment
The price of cutting corners
Not realising that Quality is a corporate asset!
What’s the best approach to manage it?
Strategically: Quality as a corporate asset - is it worth continuing to invest in it?
Tactically: use metrics as a visible feedback loop and manage repayment
Operationally: Empower the development team to focus on improving quality to reduce time to market and development costs.
Follow this three-step plan to manage your technical debt
Step 1:
Get data and insights you need to guide the identification and repayment process
Using support data and any other metrics ie estimation accuracy, create a heatmap
Showing what debt you have in which areas of the product
Get the vital answer to the question - how much debt can we handle? In other words, how much support can we throw at this until when?
Know how much (more) money you will need to invest in order to fix the current situation.
Step 2:
Create a Repayment Plan
Engage senior leaders in explaining what technical debt is & how it's impacting responsiveness, costs, delivery and morale.
Discuss your biggest pain points in business language, ie we experience a large number of tickets in X because of Y, costing 34 person-days of support effort per quarter = £/$. Time to fix this is 3 Sprints = £/$.
Explore the trade-off and the ROI.
Agree on the plan and how it will impact other work, ie this means new feature 123 will move out by 3 Sprints.
Step 3:
Create a delivery Plan
Strategically: Quality as a corporate asset - how do we best invest in this? Develop and communicate your strategy to your teams and stakeholders.
Operationally: Empower development teams to focus on improving quality to reduce time to market and development costs.
Tactically: metrics and visibility and governance needed to manage on a day by day basis. Plan to measurably reduce your debt iteratively, ie % per Sprint.
Train all your teams to spot and log technical debt on the heatmap.
Create a fit-for-purpose definition of “done” to prevent it from moving forward.
Top tip: Product Owners - pay serious attention to this. If you really insist on a compromise in this Sprint, allocate time to fix it immediately. Don’t max out your credit!
Comentários