How to deal with Technical Debt?
There are multiple ways to deal with Technical Debt. I have highlighted a few:
• Include more number of technical PBIs during the initial sprints. Development Team should spend time to perform technical analysis.
• Refer to the coding checklists and guidelines that are being followed in the organization. Follow them from beginning of the sprint. This will avoid rework.
• Perform Regression Testing every sprint. Automation of test cases will help here.
• Execute non-functional testing like performance, security etc. from very first sprint itself.
• Inspect Definition-of-Done during the Sprint Retrospective and make improvement(s) in the Definition-of-Done.
• If Technical Debts are identified, then the Development Team should be open and discuss with the Product Owner. Include relevant technical PBIs every sprint to pay-off for the technical debt.
Suppose a Product Owner deprioritizes technical debt PBIs because the comparative business value appears to be low. They always seem to end up at the bottom of the Product Backlog.
What responsibility do you think the Development Team has for resolving that situation, and what alternative technical debt policies might they consider adopting?
Development Team should convince the Product Owner and highlight the implications of not paying off for the technical debt early.
Other alternative can be to add such items in the DoD.
Please suggest if there can be any better ways!
The team has the responsibility to advise the product owner about the technical debts. But the product owner has the final decision about which PBIs are priority in the backlog. Maybe the product has to be released as soon as possible and the risks overgain the debts.
Martin fowler has one statement that we have to consider:
"you need to deliver before you reach the design payoff line to give you any chance of making a gain on your debt. Often taking on technical debt ends up slowing you down so much you end up delivering later".
Suppose the PO was not convinced, despite the Development Team's best efforts. He or she fails to see technical debt as a significant business concern, and continues to de-prioritize technical debt items. The team remain greatly concerned that the debt being accrued will eventually sink the product.
Do you think that the Development Team still bears a responsibility to remediate (pay off) that technical debt?
I understood your point. And i think the team has no responsibility of a probable failure of the product caused by a cumulative technical debt. Maybe the Scrum Master can help the team to convince the Product Owner to consider this in the management of backlog. Just a guess. Never lived this situation.
The Development Team are responsible for the technical quality of the product. It is unprofessional for them not to address it when it poses a threat to the viability of the product, or the ability to develop the product in the future.
One danger of technical debt is that if it is not repaid, it can grow, as one inferior solution is added onto another, to get around an underlying problem.
The Development Team can (and almost always should) take responsibility to prevent technical decisions that preserve the ability to develop at a sustainable pace.
One tool they have at their disposal is the definition of "Done". They could build in safeguards to prevent the accumulation of technical debt.
One such safeguard, expressed in terms that could be understood by non-technical colleagues could be:
No changes are made, that make the product harder to develop.
And i think the team has no responsibility of a probable failure of the product caused by a cumulative technical debt.
Let’s explore this a bit further. In Scrum, no-one can force a Development Team to incur technical debt, or to work on a product which they believe will eventually fail due to technical concerns.
The Development Team are responsible for the quality of their work, and for ensuring that it meets a Definition of Done which is of production standard.
A Product Owner should always expect the Development Team to “do the right thing” at a technical level, even if that means adopting a policy the PO does not currently understand or thinks to be inconvenient.
Hence it can be argued that the Development Team will always maintain a responsibility to control and mitigate technical debt, and are never absolved of that duty regardless of what a Product Owner wants to do. If the PO is unable or unwilling to prioritize debt items on the Product Backlog for example, then the team may be obliged to take the matter out of his or her hands entirely, and to adopt a different technical debt remediation policy. This could be as simple and as blunt as reserving most of their future Sprint capacity for paying off debt until the product stabilizes, and/or refusing to incur any further debt until the current liability is paid off.