Balancing Process Improvements Against Technical Debt When Tracking Velocity
Defining Technical Debt and its Impact
Technical debt refers to the implied cost of additional work caused by choosing an easy solution now instead of using a better approach that would take longer. As teams race to deliver new features, corners inevitably get cut, piling up technical debt over time. This debt manifests as difficulty maintaining and enhancing existing systems. If left unchecked, technical debt can accumulate ???interest payments???, hampering developer productivity and slowing velocity.
Common sources of technical debt include lack of documentation, outdated libraries or frameworks, copy-paste coding (duplication), hard-coding, lack of tests, violations of best practices, and choosing performance over readability. While some debt comes from conscious decisions to optimize for speed, much of it happens inadvertently over time as code evolves. The impact can be an order of magnitude slowdown in feature development.
Measuring Velocity as an Indicator of Progress
Development velocity measures a team???s rate of progress in a given sprint or iteration. Teams estimate effort for user stories in story points, then track points completed per sprint. Changes in velocity indicate whether throughput is improving or slowing down. Velocity accounting provides transparency into the team???s true cadence of feature delivery.
Technical debt drags down velocity incrementally as the code base grows harder to work with. Eventually, progress reaches critically slow levels deemed unacceptable. By this point, living with debt gets prioritized against repaying it. Just as financial debt compounds exponentially, technical debt accrues its own ???interest payments??? over time in the form of reduced productivity.
Prioritizing Debt Repayment Versus New Features
Ideally, teams would address technical debt proactively as part of regular story point estimates. However, requests for new features often take priority as they deliver direct business value. As such, tech leaders must decide how much velocity to sacrifice on security, performance, and infrastructure upgrades versus building new capabilities.
Prioritizing all debt repayment first leads to perceived stagnation, frustrating stakeholders eager for progress. On the other hand, letting debt accumulate indefinitely eventually hinders velocity to the point that no further features get built until the mess gets addressed.
Strategies for Balancing Technical Debt and New Development
Refactoring Existing Code
Legacy code often bears the brunt of technical debt, having been built quickly or maintained inconsistently over the years. Refactoring helps simplify logic flows, breaks down large procedures into composable building blocks, and updates outdated coding patterns. Such renovation improves readability, maintainability and extendability.
Refactoring should happen continually rather than waiting for hard failures. Setting aside 20% of each sprint for paying down debt creates a force multiplier over time. Automated test coverage gives teams safety nets for continuously improving existing implementations without breaking features.
Limiting Code Complexity in New Features
While refactoring addresses past sins, modern coding practices help minimize accruing further debt. Simple, well-factored logic encapsulated in small, single-purpose modules and classes avoids tangled dependencies over time.
Code reviews catch potential debt before merging to the main branch, giving reviewers a chance to share constructive suggestions for improving code quality and maintainability. Strong typing, linting, static analysis, and adhering to style guides optimize for readability and reuse.
Setting Velocity Goals for Debt Repayment
Rather than deferring debt repayment indefinitely, leadership should set velocity-based goals for upgrading technical infrastructure. For example, mandating at least 10 story points per sprint dedicated to paying down debt. This goal yearly could eliminate large swaths of cruft, freeing up velocity.
Such goals incentivize architects and engineers to plan diligent remediation efforts. Business sponsors then get visibility into the returns expected from modernization investments ??? cleaner code, reduced outages, quicker onboarding of new team members, etc.
Communicating Tradeoffs Across Teams
Product teams tend to prioritize end-user functionality over underlying technical improvements which don???t directly generate revenue. This tension often leads to resentment between business and technology groups.
Effective legacy modernization requires their alignment. Technology leaders should actively discuss the hidden costs of technical debt with product owners to find acceptable rates of repayment. Such collaboration results in shared vision and a balancing of priorities, rather than unilateral compromises undermining one group???s commitments.
Managing Stakeholder Expectations
Non-technical stakeholders commonly lack visibility into brewing issues like technical debt. Their focus stays fixed on outward-facing features. Accordingly, tech leaders must reveal the ???messy engine room??? issues jeopardizing future velocity.
Illustrating how declining developer productivity threatens the long-term feature roadmap sets the stage for investments in remediation. Rather than surprises down the line, executives appreciate transparency into tradeoffs between maintenance and new functionality based on limited resources.
Key Takeaways and Best Practices
Letting teams focus solely on new features builds exciting momentum in the short term but slows velocity drastically in the long run. On the other hand, prioritizing all technical debt cleanup starves stakeholders wanting progress. Balancing these competing tensions requires actively quantifying and communicating tradeoffs between repayment and feature development.
Combining reflected legacy upgrades with a sharp focus on resilient modern code practices prevents velocity from flatlining completely. Frequent, incremental improvements avoid major disruptions down the line. With shared accountability towards this vision, technology, process and people all accelerate together in unison.
