Notes: Managing technical debt in Agile

This week I attended a webinar on "Managing Technical Debt with Agile" by Michael Hall, of Three Beacons. “Technical Debt” often comes from choosing a design approach for expedience that, over time, increases complexity and costs. The financial metaphor is that of credit: to get something now, pay for it later, but with interest — which can worsen to the point that all money (effort) is going into servicing that debt, which can never be paid off. Mike offered three areas of suggestions: how to prevent new debt from occurring, how to deal with new debt that happens, and how to bring down legacy debt:

• Stopping new debt
  1. Culture shift: "From this day forward, we no longer allow technical debt, unless there's a solid business justification"
  2. Strong and visible “Definition of Done”: 
     • Coding standards adherence
     • Code reviews
     • Complexity analysis
     • Written unit tests
     • 0 known bugs
     • Test cases passed, automated
  3. Test-Driven Development (TDD): write test, fail the test, then write code to pass the test. Refactor when needed. Produces higher-quality, streamlined code
  4. Collaborative Designs: More whiteboard sessions on design topics, less over-reliance on subject-matter experts
• Dealing with new debt
  1. Debt Backlog, for debt that is business-justified
     • Track DEBT by name and list work tasks associated
     • Track the "commitment to fix" schedule (which sprint to resolve by)
     • Keep the debt service level visible, and track debt dynamically
  2. “Service the Debt” Commitment
     • Always include a debt item in a sprint ASAP
     • Service the debt as you go! Keep it as close to $0 as possible
  3. "Makeup Stories": they apologize to the code base and promise to fix it!
     • Non-user story work for any time you circumvented quality
     • Add it to the product backlog, but make visibly different, for tracking/reporting
     • Prioritize into next sprint (if possible)
  4. Makeup Stories - have them "adopted" by related User Stories
     • Good way to ensure that makeup stories get worked
     • If a user story leverages the debt area, include the makeup story as part of the effort
  5. Dedicated sprint to service debt, or combine with bugfix sprints
• Dealing with legacy/inherited debt
  1. Re-Do Project (total redesign and rewrite) almost never worth it, unless for new technology
  2. “Small Chunks” Approach
     • Smaller chunks of effort done within normal dev flow
     • Can work well across an API abstraction
     • Often requires architectural assessment
     • Risk: Can require code changes to other parts of legacy base
  3. 70 / 30 Rule
     • 70% - new user stories, 30% - paying down legacy debt
     • Best with a PO who has history with the legacy system
     • Rule also works to manage new technical debt
  4. “While There” Rule: 
     • While adding a new feature, any legacy function touched must be reworked to coding standards
     • Works well for support team also (while fixing bugs)
     • Risk: may introduce bugs

“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)