Managing Technical Debt with Agile

1. Types of Technical Debt

An outline to use when discussing technical debt:

1. Unintentional
2. Intentional:
   (a) Short-term: Only if there is the commitment to schedule, prioritize, and fix soon (e.g., in the next sprint).
   (b) Long-term: Only if the commitment is there to sponsor projects to resolve the debt.

A short-term debt is a reactive and tactical measure (pushing a release with known Severity 3 bugs), whereas a long-term one is a proactive and strategic one (not providing support for a platform that may not exist after two to three years). The implication is that short-term debt should be paid off quickly, preferably as part of the next release cycle, whereas long-term debt can be carried on for a few years or longer.

Classifying technical debt

Martin Fowler’s technical debt quadrant gives us a clear picture of what technical debt is.

Figure 1: Technical debt grid quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

This could be used in organizations to decide which sources of debt are acceptable and which are not, and to use the information to establish tactics for preventing unacceptable behavior.

1. Prudent and Deliberate
   This quadrant is reserved for business drivers who have a compelling ROI for why a product has to ship immediately, i.e., responding to a threat to the business bottom line or exploiting an opportunity that positively affects the bottom line. Examples where this could be justified might be:
   • Entry into a new market – first to market may mean that lower quality or features with more workarounds might be acceptable.
   • Regulatory or legal requirement – in compliance projects, not meeting dates could have a severe financial and operational impact on the business.
   • Peak-period opportunity – within retail, the Christmas period is increasingly becoming the most critical part of the annual cycle, and failure to launch prior to Christmas could have a significant negative impact on the company’s performance.
2. Reckless and Deliberate
   This quadrant reflects poor management, where usually corners are being cut in order to hit a deadline that is related to perceived operational needs rather than an underlying clear business case. This is a very common cause of technical debt.
   Examples include:
   • Rushing the project to completion because there are lots more projects to deliver in the pipeline.
   • Pushing the project through because the client wants it on a set date, and no one has built a relationship with the client to discuss the details, nor has the client been informed of the effect on quality if the delivery is rushed.
   • Cutting corners because teams have been incentivized to deliver projects into production by a specified date.
3. Reckless and Inadvertent
   This happens typically to programmers who are incompetent and unaware of the implications of adding/removing a piece of code, thus incurring a huge technical debt. Technical debt in this quadrant needs to be carefully managed by using processes and tools – through pair programming, code reviews, continuous integration, automated testing, etc.
4. Prudent and Inadvertent
   This is a natural occurrence. Teams would like to improve upon whatever has been done after gaining experience and relevant knowledge.

Technical debt in legacy projects

According to James Shore, one of the biggest problems facing legacy projects is excessive technical debt, due to which velocity takes a huge hit. Typically in a legacy system, so much work goes into keeping a production system running (i.e., „servicing the debt“) that there is little time left over to add new capabilities to the system. The „bleeding“ has to be stopped to prevent more technical debt from occurring.

Besides the use of practices such as test-driven development and continuous integration, it would be preferable to set apart a certain amount of time as „slack“ time during each iteration to service technical debt. Though these measures may not be fruitful for the first few iterations, it should be possible to see improvements in quality and productivity over a period of time.

Attitudes toward technical debt

Different companies have different philosophies about the usefulness of technical debt, just as they do with financial debt. Some companies want to avoid taking on any debt at all, while others see debt as a useful tool and just want to know how to use it wisely.
Few companies track debt versus team velocity. Once a team’s velocity begins to drop as a result of servicing its technical debt, the team focuses on reducing its debt until its velocity recovers. Other approaches include tracking rework, and teams use that as a measure of how much debt they are accumulating.

2. Different Techniques for Preventing Technical Debt

1. Draw the Line
   Culture shift:
   – From this day forward…
   – We no longer allow technical debt!
   – The only exceptions are tactical or strategic business justification
2. Strong “Definition of Done”
   Things to consider:Coding standards adherence
   – Code reviews
   – Static analysis
   – Dynamic purification
   – Complexity analysis
   – Written unit tests
   – 0 known bugs
   – Test cases pass
   – Test cases automatedVisible for:
   – User story
   – Sprint
   – Release
3. Test-Driven Development
   
   TDD: Write test, fail the test, and then write code to pass the test. Refactor when needed. Develop higher quality streamlined code.
4. Collaborative Designs
   – Whiteboard sessions on design topics
   – Leverage collective experience of the team
   – Wisdom of the crowd
   – User design studio
   – Less reliance on subject-matter experts

3. Techniques for Managing Technical Debt with Agile

1. 3.1. Debt Backlog
   – Used when technical debt is business-justified
   – Tracks debt by name
   – Lists work tasks associated with each debt
   – Includes an estimate
   – Tracks the commitment to fix schedule
   – Form: product backlog entries, separate Excel spreadsheet, special designation in defect DB, tool entry, sticky notes, etc.
   – Track the debt as you go!

   Debt backlog –example

2. “Service the Debt” Commitment
   – Include technical debt items in upcoming sprints
   – As quickly as feasible
   – In line with fulfilling commitment made when debt was justified
   – Service the debt as you go! Keep it as close to $0 as possible
3. Makeup Stories – a Good Way to Track Technical Debt
   – “Makeup”: a story that apologizes to the code base – and promises to fix it!
   – Placeholder indicating non-user story work – for when you incur technical debt, for any reason you circumvented quality, use a different color card (red or pink is good)
   – Add it to the product backlog
   – Prioritize into next sprint (if possible)

   Makeup stories – example

    

4. Makeup Stories Adopt – a Good Way to Ensure that Makeup Stories Get Worked
   – “Adopt” approach
   – If a user story leverages the debt area, “adopt” the debt card as part of the user story effort
   – Add the makeup story estimate into the user story
   
5. Dedicated Sprint to Service Debt
   – Similar to a “bug fix sprint”
   – Do this only if really needed – preponderance of business debt occurring during project, team concerned about debt growth, upcoming features rely on code that has debt
   – Or, combine for a bug fix/debt sprint
   – Periodically pay down your debt throughout the project!

4. Managing Technical Debt – Conclusion

It is important that organizations take cognizance of technical debt and find ways and means to manage it efficiently to prevent a system collapse.
“Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills” –Robert C. Martin (Uncle Bob), president of Object Mentor and agile methods author.

References:

Mike Cohn, Succeeding with Agile
James Shore, Art of Agile Development – http://www.jamesshore.com/Agile-Book/
http://www.threebeacons.com/
http://www.scrumalliance.org/articles/14-technical-debt-and-design-death
http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://www.construx.com/10x_Software_Development/Technical_Debt/
http://www.ontechnicaldebt.com/slideshare/technical-debt-the-silent-application-killer-graham-brooks/
http://www.ontechnicaldebt.com/slideshare/credit-crunch-code-paying-back-the-technical-debt-gary-short/