7 min read
Refactoring often gets sidelined in favor of delivering features or fixing defects. However, its business value lies in enabling teams to work faster, reduce long-term costs, and provide better customer experiences. We must go beyond identifying its value to advocate for refactoring while integrating it effectively into broader prioritization frameworks. We must determine how to prioritize refactoring work against competing demands: features, defects, and risks.
“It’s not about perfect code; it’s about creating systems that adapt and deliver value as your business and customers evolve.”
This article explores the following:
- The case for refactoring as a business priority.
- How we get into situations requiring Refactoring.
- The challenges of prioritizing refactoring alongside other types of work.
- Tools and approaches to balance refactoring with business goals.
- How Value Stream Management (VSM) and the Product Operating Model (POM) provide the foundation for prioritization.
- Documenting technical debt agreements in Jira.
The Business Case for Refactoring
Refactoring improves the maintainability, scalability, and reliability of software systems. The outcomes directly tie back to business value in several ways:
• Faster Feature Delivery: Clean code enables quicker development of new features, allowing teams to respond to customer needs faster.
• Reduced Defect Rates: Simplified codebases decrease the likelihood of bugs, reducing operational costs and improving customer satisfaction.
• Scalability for Growth: Refactored code can handle growing user demands without performance degradation.
• Developer Productivity: Clearer, less complex code reduces onboarding time and empowers engineers to contribute more effectively.
As I’ve shared in past discussions, “Every sprint is an opportunity to balance speed with sustainability. Ignoring refactoring today compounds the cost of tomorrow’s delays.”
How We Get Into Situations Requiring Refactoring
The need for Refactoring arises from various common scenarios, most of which stem from trade-offs made during the software development lifecycle:
1. Corner-Cutting Due to Deadlines
Under tight deadlines, teams often implement workarounds or suboptimal solutions to meet delivery goals. They do this with the intention of revisiting the code later, but other priorities often take precedence, leaving technical debt unresolved.
2. Building to Learn Instead of Building to Scale
When products are in early development, the focus is on validating ideas rather than scalability or long-term maintainability. While this approach helps teams experiment and adapt quickly, it often results in code that requires significant Refactoring once the product matures.
3. Evolving Requirements and Legacy Code
As products grow, their requirements evolve, often leading to layers of new functionality added to an older codebase that was not designed to accommodate these changes. Over time, this creates tangled dependencies and poor maintainability.
4. Insufficient Testing Practices
Low test coverage or reliance on manual testing increases the risk of defects when refactoring or updating code. This creates resistance to Refactoring, as teams fear introducing bugs.
5. Lack of Team Discipline or Standards
Inconsistent coding practices, poor documentation, or lack of adherence to architectural guidelines can make it harder to maintain and understand code, making refactoring a necessity later.
6. Growth in Scale or User Base
As the user base grows, systems that are sufficient for small-scale use start to show performance bottlenecks. Refactoring becomes essential to scale effectively.
7. Engineers’ Evolving Skills and Knowledge
Engineers write the best code they can with their knowledge at the time. As they gain experience, they may revisit old code and see ways to improve it. The code they wrote at the time isn’t due to poor effort but reflects their growth. Many engineers can relate to looking back and thinking, “Wow, did I write this?” Refactoring helps align the code with their current skills. As I’ve often said, “We don’t regret the skills we had at the time, but we owe it to the future to evolve them.”
8. Ignoring Continuous Refactoring Practices
Refactoring doesn’t always need to be a significant, disruptive event. A more sustainable approach is continuous refactoring, where developers clean up the areas of code they touch while working on other tasks. This practice prevents technical debt from accumulating to unmanageable levels.
- By incorporating small, incremental improvements into daily work, teams can avoid the need for massive, time-consuming refactoring efforts later.
- Think of it as weeding a garden: You can pull the weeds every time you’re in the garden, or you can wait until they overtake the garden, requiring significant effort to clean up.
The Four Types of Work in Software Development
Every engineering team must balance the following types of work:
- Features: Adding new capabilities or value for customers.
- Technical Debt: Addressing shortcuts or suboptimal code that slows teams down.
- Defects: Fixing bugs that impact customer experience or system performance.
- Risk: Mitigating potential security vulnerabilities or regulatory compliance gaps.
Refactoring, categorized under technical debt, often faces challenges in prioritization due to its indirect benefits. The difficulty lies in quantifying its immediate impact relative to features, defects, or risks.
Integrating VSM and POM into Refactoring Advocacy
Teams can use the frameworks of value stream management (VSM) and the product operating model (POM) to bridge the gap between identifying the value of Refactoring and effectively prioritizing it.
1. Visualize the Entire Value Stream
By mapping the entire value stream, teams can pinpoint bottlenecks and inefficiencies where technical debt impedes flow. As I shared in a recent article, “The power of VSM lies in its ability to connect engineering improvements to measurable business outcomes, making investments in refactoring an organizational priority, not just a technical one.”
Refactoring can then be prioritized where it delivers the most significant value:
- High-Impact Refactoring: Focus on areas where complexity delays delivery or introduces recurring issues.
- Alignment with Business Objectives: Ensure refactoring initiatives directly address bottlenecks that impact customer value or strategic goals.
2. Align Refactoring with the Product Operating Model
The POM emphasizes cross-functional teams focused on delivering end-to-end value. Refactoring fits seamlessly into this model:
- Collaboration: Engineers, product managers, and stakeholders work together to identify refactoring needs that align with business priorities.
- Outcome Orientation: Refactoring is viewed as a driver of faster delivery, better scalability, and reduced costs—outcomes directly tied to business success.
3. Use Flow Metrics for Prioritization
Flow metrics, as discussed in VSM, provide quantifiable insights into areas where technical debt hinders efficiency:
- Flow Time: Highlight parts of the value stream where technical debt increases lead time.
- Flow Efficiency: Identify opportunities where Refactoring could significantly boost the ratio of active work time to total time spent.
These metrics help teams prioritize refactoring efforts that will deliver the most significant improvements in flow and business results.
4. Establish a Feedback Loop for Continuous Improvement
To ensure Refactoring aligns with business outcomes, establish a cycle of regular evaluation and adjustment:
- Monitor Key Metrics: Track deployment frequency, defect rates, and time-to-market improvements after refactoring.
- Adjust Prioritization: Use data-driven insights to refine future sprints or quarter priorities.
Prioritization Framework: Outcome-Driven Decision-Making
To ensure Refactoring receives the attention it deserves, teams must prioritize all work based on outcomes and impact on business goals rather than categorizing tasks in silos. Here’s a framework to guide this process:
1. Measure the Business Impact
Evaluate each piece of work (feature, Refactoring, defect, or risk) based on how it contributes to:
- Business goals: Revenue growth, market share, cost savings, or customer retention.
- Customer value: Improved experience, performance, or satisfaction.
• Operational efficiency: Faster time-to-market, reduced downtime, or lower maintenance costs.
2. Use Weighted Scoring for Prioritization
Apply a prioritization matrix that scores tasks based on:
- Impact: The anticipated outcome (e.g., faster delivery, fewer defects).
- Effort: The time and resources required to complete the work.
- Risk: The potential consequences of not addressing the issue (e.g., customer churn, security vulnerabilities).
- Time-to-Value: How quickly the outcome can be realized.
3. Prioritize Quick Wins and High Impact
Sometimes, smaller tasks can deliver faster outcomes:
- A small refactoring task might unblock multiple feature requests.
- Addressing a piece of technical debt might prevent significant defects or downtime.
4. Incorporate Refactoring into Regular Work
I often advise, “Refactoring doesn’t have to derail your sprint—it can fuel your delivery. Incremental improvements sustain momentum and build long-term agility.”
- Incremental Refactoring: Dedicate a percentage of sprint capacity (e.g., 10-20%) to Refactoring.
- Bundled Refactoring: Tie refactoring to new feature development.
- Refactoring Backlog: Maintain a prioritized backlog of technical debt items for continuous improvement.
Documenting Technical Debt Decisions in Jira (or equivalent)
Teams can use labels or custom fields in Jira to document technical debt agreements at the epic level to ensure that shortcuts and technical debt are visible, traceable, and manageable.
1. Create a “Technical Debt Agreement” Label
- Add a label or custom field to epics that identifies when a shortcut has been taken, such as tech-debt-agreement.
- Use the description field or a custom template to document:
- The reason for the shortcut (e.g., tight deadlines, experimental approach).
- The impact of the debt (e.g., increased complexity, scalability risks).
- An estimated timeline or trigger for addressing the debt.
2. Tie the Agreement to Outcomes
Connect the technical debt to business goals, prioritizing it based on its impact on customer value or operational efficiency.
3. Use Jira Dashboards to Track Technical Debt
Set up a dashboard to track all epics labeled with tech-debt-agreement.
4. Create a Review Cadence
Review open technical debt agreements during backlog grooming or sprint planning.
Conclusion
Refactoring is not just a technical activity; it’s a strategic investment in the health of your product and its ability to deliver value to customers and the business. By understanding how we get into situations requiring Refactoring, integrating frameworks like VSM and POM, and applying prioritization tools, teams can ensure Refactoring is prioritized effectively.
As I’ve said in presentations and writing,
“Every improvement we make—whether in our code or our process—is a step toward becoming the winning team.”
Documenting decisions with tools like Jira and fostering a culture that values refactoring help build a foundation for sustainable delivery. This approach ensures that refactoring competes fairly with features, defects, and risks, driving long-term success.
Poking Holes
I invite your perspective on my posts. What are your thoughts?
Let’s talk: [email protected]