Rethink Your Understanding

Transforming Software Delivery

Value Stream Management

Why Cutting Agile Leadership Hurts Teams More Than It Saves

by

8 min read

The Cost-Driven Decision That Many Companies Regret

Many organizations today are eliminating the Scrum Master or equivalent Agile leadership role, not to rebrand it but to cut costs. Instead of keeping Agile leadership as a dedicated role, they distribute its responsibilities across existing team members:

  • Engineering Managers take on Agile execution and delivery oversight.
  • Product Managers absorb backlog management, facilitation, and team coordination.
  • Team members self-manage Agile ceremonies, tracking, and reporting.

At first glance, this is a logical cost-saving move. Mature teams should be able to self-organize. But the reality is far more complicated.

In our company, we’ve seen firsthand that keeping Agile leadership as a distinct role pays off significantly more than the salary it costs.

Why We Didn’t Eliminate This Role

Like many organizations, we’ve gone through multiple Agile transformations:

  • Waterfall to WaterScrumFall – Agile sprints, but still project-driven release cycles
  • Scrum to Kanban & Flow – Shifting toward continuous delivery and flow efficiency
  • Scrum Master to Agile Leader to Agile Delivery Manager – Evolving the role encompassing Flow Metrics, Value Stream Management (VSM), Flow Engineering, and continuous optimization.

Rather than eliminate the role, we adapted it to better match how our teams and technology operate today.

We’ve moved away from Scrum and now use a Kanban flow with a few Scrum ceremonies mixed in. As a result, we changed the role name from “Agile Leader” since neither “Agile Coach” nor “Scrum Master” fit the way we work or the responsibilities of the role.

Meanwhile, our parent company, which structured product teams differently, removed the Scrum Master and QA roles, pushing those responsibilities onto Product and Engineering Managers. This team design isn’t inherently wrong, but it does fundamentally change team dynamics and, in our experience, weakens long-term effectiveness.

Our support for this role deepened when we began adopting Value Stream Management in 2020 and 2021. As we learned more about optimizing the flow of work across the system, aligning delivery to OKRs and business outcomes, and using Flow Metrics to identify bottlenecks, we made a key decision: rather than hire a value stream architect or separate value delivery lead; we assigned that accountability to the Agile Leader. That move became a turning point. The role now included facilitation, value stream management, flow engineering, and cross-system delivery health. This expansion of responsibility led us to retitle the role of Agile Delivery Manager.

The Hidden Cost of Eliminating Agile Leadership

Many companies assume Agile execution can take care of itself. But what happens?

  • Engineering Managers are already stretched managing technical leadership, hiring, mentoring, and architecture. Adding Agile execution oversight creates competing priorities.
  • Product Managers are tasked with strategy, roadmap, and customer insight. When they absorb Agile execution, their ability to drive innovation and product-market fit suffers.
  • Teams default to feature-first work without someone to balance priorities across features, tech debt, security, and defects.
  • The erosion of Agile leadership often leads to a breakdown in psychological safety, team culture, and continuous improvement. Agile leaders aren’t just facilitators but team enablers who cultivate trust, alignment, and growth.

The impact of cutting or removing the dedicated agile leader role from teams isn’t a theoretical concern. We’ve seen organizations eliminate the role and reinstate it later after delivery slowed, burnout spiked, and alignment broke down.

What Happens When Agile Leadership Is Removed?

When Agile leadership is absorbed rather than owned, teams face:

1. Increased Cognitive Load for Engineering & Product Managers

  • Engineering Managers are expected to facilitate Agile ceremonies, track team health, and optimize delivery on top of leading architecture and engineering excellence.
  • Product Managers now manage the backlog, facilitate delivery, and maintain customer alignment all at once.

2. Reduced Flow Efficiency & Team Alignment

  • Work is optimized for speed over value, with more features and fewer strategic investments in quality, sustainability, or security.
  • No one is clearly accountable for balancing work types across the system.

3. Breakdown in Agile Practices, Psychological Safety & Team Culture

  • Retrospectives lose impact without consistent facilitation.
  • Process improvements stall without clear ownership.
  • Team culture and psychological safety erode, affecting engagement, retention, and long-term execution health.

The Agile Delivery Manager: More Than a Facilitator

As our practices evolved, the role titles and responsibilities changed as well. 2025, we’re updating it from Agile Leader to Agile Delivery Manager. The Agile Delivery Manager (ADM) is more than just a renamed Scrum Master; it’s an evolved form of Agile leadership designed to ensure:

  • Agile leadership is a focused role, not something to divide among the team  
  • Flow Metrics and Value Stream Management (VSM) help improve overall system delivery  
  • Teams prioritize both feature development and maintaining system health, technical debt, security, and fixing defects  
  • Psychological safety, collaboration, and a strong culture are actively maintained

Unlike Product Managers (incentivized to deliver features) or Engineering Managers (focused on technical excellence and delivery), the ADM has no stake in any single type of work. This neutrality is essential. They provide a holistic, unbiased lens on the system, ensuring balanced Flow Distribution and healthy delivery over time. Without this role, teams prioritize visible work and short-term wins, neglecting foundational needs.

What the Experts Say About Scrum Masters and Why It Still Matters

Some well-known Agile voices have described the Scrum Master as a servant-leader, facilitator, and invisible guide:

“Great Scrum Masters don’t manage the team; they enable the team to manage themselves.” – Gunther Verheyen, author of Scrum – A Pocket Guide

“A good Scrum Master is invisible. A great Scrum Master makes the team feel like they did it themselves.” – Geoff Watts, Agile coach and author

“The role of the Scrum Master is not to ensure Scrum is implemented correctly. It’s to ensure that the team continuously improves and delivers value.” – Scrum.org Blog

“Without a dedicated Scrum Master, teams often fall back into old habits, status reporting, command-and-control, and short-term delivery over long-term health.” – Agile coach insight, echoed across retrospectives and forums

These quotes reflect the foundational role the Scrum Master plays in enabling self-managing teams, continuous improvement, and long-term value delivery.

However, the role must evolve as the team matures. When teams move beyond needing constant facilitation, the Agile leader doesn’t become unnecessary; they become more strategic. They step into a broader role: optimizing flow, supporting cross-functional alignment, stewarding system health, and driving outcome-based delivery.

Rather than disappearing, the Agile leader becomes even more critical, not as a passive servant but as a system-level enabler of delivery efficiency and value.

Lessons from Inside: Comparing Team Models

I’m fortunate to work in an organization that supports both models: teams with dedicated Agile Delivery Managers and teams with responsibilities assigned to Engineering Managers. This side-by-side comparison has been revealing. Engineering managers in teams without an ADM often struggle to juggle architectural leadership, people management, Agile ceremonies, psychological safety coaching, and flow metrics. The burden is real, and it dilutes their impact across all fronts. What gets lost is not just ceremony facilitation but sustained attention to team health, value delivery, and process evolution. These teams tend to operate reactively without a clear guide focusing on system optimization.

That said, I also recognize that some long-lived, high-performing teams have matured to the point where they can self-manage without formal Agile leadership. These teams have developed strong cultures, embedded trust, and deep internal accountability. In those environments, the absence of a dedicated ADM may not be felt day-to-day.

However, this raises an important question: Who is responsible for reporting on delivery health, aligning with outcomes, and guiding continuous optimization across the system? That’s not a critique; it’s just something worth considering.

Different Models, Different Choices

To be clear, I’m not saying one model is right and the other is wrong. I’m sharing what I’ve seen work and where things fall apart.

Different organizations, maturity levels, and team cultures will demand different approaches. But understanding the trade-offs is key. Eliminating Agile leadership may save salary dollars, but it can cost far more in lost alignment, missed improvement opportunities, and team degradation over time.

Key Responsibilities of the Agile Delivery Manager

  • Agile Leadership & Flow-Based Delivery
  • Facilitate planning, stand-ups, retrospectives, and production reviews
  • Align teams around roles and responsibilities and work across the value stream
  • Champion flow efficiency by removing bottlenecks and managing work intake
  • Foster psychological safety, trust, and continuous learning
  • Value Stream Management, Flow Engineering, and Flow Metrics Optimization
  • Lead monthly Flow Metrics reviews to help teams surface and resolve inefficiencies
  • Track Flow Time, Efficiency, Load, Velocity, and Distribution
  • Ensure investment in tech debt, security, and sustainability, not just features
  • Cross-Team Collaboration & Dependency Management
  • Align Product, Engineering, and Agile leadership
  • Coordinate across teams to manage dependencies and reduce delivery friction
  • Partner with Platform and Production Engineering teams for smoother execution

The Unicorn Problem: Why Overloading Other Roles Fails

Some argue that Product and Engineering Managers can take on these additional responsibilities, but at what cost?

The industry already struggles to fill these roles with strong candidates. When you ask one person to manage delivery flow, facilitate team dynamics, coach culture, drive Agile execution, and lead strategy, you create what I call the “unicorn problem.”

  • T-Shaped Leaders = Deep expertise in one area + a broad understanding of others
  • V-Shaped Leaders = Deep expertise in everything (engineering, Agile, customer insight, facilitation, coaching, metrics, and more)

Unicorns exist but rarely and not for long. Overloading these roles doesn’t set anyone up for success.

Should You Drop the dedicated Scrum Master or Agile Leader Role?

Most organizations still have a Scrum Master or equivalent Agile role, but some are experimenting with eliminating it in favor of shared responsibilities.

While this can work in some instances, our experience proves that a dedicated Agile leadership role improves:

  • Delivery flow efficiency
  • Business alignment
  • Sustainable team execution
  • Psychological safety and culture

So before you eliminate the role, ask: Who on your team is incentivized to prioritize delivery balance across features, tech debt, security, and defects? If no one owns that responsibility, it’s likely no one is doing it well.

Again, I’m not prescribing a one-size-fits-all answer. I’m sharing what I’ve seen in practice, from teams that struggled without this role to high-performing teams that outgrew it to the evolution of the ADM as a critical driver of system-wide value delivery. The key is clarity of purpose and accountability, no matter the model.

“Agile leaders don’t just guide their teams. They protect and improve the entire delivery system. They play a key role in ensuring its integrity and success. They are the guardians of the delivery system.” – Phil Clark

What’s your experience?

  • Has your organization eliminated this role?
  • If so, what impact has it had?
  • Should Agile execution be absorbed by Engineering and Product Managers?

Let’s keep the conversation going.

Related Posts

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: [email protected]

Avoiding Flow Metric Confusion: Aligning Agile Work Hierarchy to Flow Items

by

10 min read

Adopting Flow Metrics without understanding Value Stream Management, Flow Items, and the Agile Work Hierarchy can create confusion and misalignment. Connecting Agile work to Flow Items becomes challenging without this foundation, making it harder to measure and improve value flow. This article simplifies these concepts to help teams and leaders align Agile work with Flow Metrics, enabling better visibility and greater efficiency.

A common issue I’ve noticed is misinterpreting Agile work elements when modeling Flow Items. Many organizations don’t fully understand or follow the standard Agile Work Hierarchy.

This article aims to guide leaders in understanding and applying a framework to align Flow Items while exploring essential Value Stream concepts. Drawing from my experience, I’ve crafted this guide to simplify and make these topics more accessible. I hope it will provide valuable insights and practical tools for others navigating similar challenges.

Misunderstanding Resulting in Confusion

Recently, I observed a Technology division new to Flow Metrics trying to map their Jira Issue types to Flow Items. It was clear they didn’t have a solid understanding of the scope and context of a Flow Item. On top of that, multiple product and platform teams had the freedom to structure and manage their Jira instances however they wanted, with no effort to follow even basic industry guidelines. The teams had so many custom types that some members even argued tasks were deliverables, causing confusion between hierarchy levels and Flow Items.

Clearing the Murky Waters

I created the following Agile Work Hierarchy model to help teams standardize their project tracking tools, have a common language, and better align with Flow Items:

The Agile Work Hierarchy as commonly defined by industry standards

  1. Theme: At the top of the hierarchy, themes represent broad organizational goals or focus areas. They align teams and ensure all work supports overall business objectives.
  2. Initiative: A business objective made up of multiple epics working together to achieve a broader organizational goal or outcome.
  3. Epic: A large body of work that support the initiative and that can be divided into multiple features or user stories.
  4. Feature: A product function or characteristic that delivers value to the user. It typically originates from an epic and is further broken down into user stories.
  5. User Story: A simple, user-centric description of a requirement or request that explains a specific feature or function needed by the user.
  6. Task: A granular unit of work necessary to complete a user story. These are actionable steps assigned to team members.

“”Theme” isn’t an official Scrum term but is commonly used in Agile practices. Whether you view Themes and Initiatives as the same or different doesn’t impact the focus of this discussion. The key is to identify the right level of work items for Flow Metrics and Flow Items, regardless of naming conventions, to effectively map core work items in your practice.

The names used for work types in delivery tracking can vary depending on the platform or tools. For example, our teams have worked with two popular tools: Jira and Rally. Rally and Jira use different terms and structures for Agile work items and workflows, particularly in their terminology and hierarchy.

Rally

  • Initiatives/Epics: Rally uses Portfolio Items to represent high-level work, such as initiatives or epics, that align with strategic goals.
  • Features: These are essentially lower-level Portfolio Items used to group related user stories.
  • User Stories: Rally uses user stories as a key work item, aligned with Agile principles.
  • Tasks: These are smaller parts of user stories, breaking the work into more manageable steps.

Jira

  • Initiatives/Epics: Jira uses Epics for large bodies of work and supports an additional layer (e.g., Initiatives) with advanced roadmaps in premium plans.
  • Features: Jira doesn’t specifically label items as “features.” Instead, it often uses Epics or custom issue types to serve a similar purpose.
  • User Stories: User stories are tracked as Issues and can be customized with different fields and workflows.
  • Tasks: Tasks are a basic issue type in Jira, with sub-tasks available for more detailed tracking.

This post isn’t about recommending a specific labeling structure. It’s about understanding your work hierarchy to align your flow items with the smallest deliverable unit that adds value to your customer or organization.

We use an initiative-epic-user story-task hierarchy to structure work. Teams organize epics, which break down into smaller user stories. These stories are the main work items, mapped to flow items and represent the smallest units of value delivered to production and customers. Our process doesn’t include a feature layer.

Addressing Release Misconceptions

Another common misunderstanding I encountered in a different division was how Product Managers using Aha! defined their work hierarchy. They categorized the highest-level program element as a “Release.” However, a release is not a work item in the industry-standard hierarchy. It is a scheduled deployment of a set of features or functionalities to the customer. A release can include multiple features, which in turn contain user stories and tasks. Misusing this term can lead to confusion in workflow tracking and alignment across teams. You don’t need to change how you and your teams label your levels, but it’s important to have clear, aligned definitions to help identify Flow Items.

Flow Items in Flow Metrics

Flow Items In Project to Product, Dr. Mik Kersten defines Flow Items as the primary units of work that move through a software value stream. These items fall into four categories:

  • Features: New functionality delivering business value to the customer.
  • Defects: Work items addressing quality issues impacting the user experience.
  • Risks: Tasks focused on mitigating security, compliance, or governance concerns.
  • Debts: Efforts improving system health, such as code refactoring or infrastructure updates.

These categories ensure that all work flowing through a value stream is accounted for and measured effectively.1

Clarifying Flow Items in the Agile Work Hierarchy

In Agile methodologies, it’s common practice to decompose Epics, Features, and User Stories into the smallest units of work that can deliver value independently. For instance, teams often aim to deliver User Stories sized at three to five story points, ensuring each piece is manageable and valuable.

Drawing insights from Mik Kersten’s Project to Product and the concept of Flow Metrics, I define a Flow Item is the smallest unit of work that delivers meaningful value to the user or the business. Even if all other work stops, delivering this item will still result in a clear benefit. Whether your organization calls them Features or User Stories, the key is that each Flow Item must deliver value on its own.

An anti-pattern to be cautious of involves breaking down work into segments that when delivered individually, don’t provide standalone value. For example, delivering only the URL endpoint for an API without its functional components doesn’t offer immediate value to the customer. Such practices can lead to misleading metrics, suggesting progress where the end-user perceives none.

To align Flow Items correctly with Agile work elements, I created a version of the Agile Work Hierarchy that follows the industry naming guidelines and highlights Features as the Flow Items (or User Stories depending on your context). Remember Flow Items should be the smallest units of work that deliver value to customers.

In the Agile hierarchy I’ve outlined, a Flow Item most closely aligns with a Feature. While User Stories are smaller, detailed requirements that contribute to a Feature, the Flow Framework operates at a higher level, focusing on the delivery of Features as complete units of value. 1

or depending on your context

or how we manage work

The goal is to choose one approach and stick with it. The key is to have a clear, standardized unit of work. It’s crucial to ensure that teams fully understand your definitions and how your work items align with Flow Items.

Clarifying Value Streams, Stages, and Mapping

This article does not aim to provide an in-depth education on Value Streams, as there are many excellent resources available to help you and your teams explore Value Streams and Value Stream Mapping. However, adopting Flow Metrics without first investing in this foundational knowledge can lead to significant challenges. Organizations often struggle to define a Value Stream, understand its components, and connect these elements to mapping efforts. Common difficulties tend to arise in four key areas:

  1. The Scope or Definition of a Value Stream
    • A Value Stream represents the entire end-to-end process from concept to cash (or value realization) of a Product.
    • A Value Stream should cover the entire product or product portfolio, including all teams and team members involved.
  2. The Stages or Phases of a Value Stream
    • Many teams confuse operational execution tasks with high-level Value Stream stages.
    • The Value Stream Model is typically presented as a series of distinct stages: Discovery, Delivery, Operation, and Support. Each stage represents a critical phase in the process of creating and delivering value.
  3. The Steps That Are Used to Create a Value Stream Map
    • Value Stream Mapping involves breaking down high-level stages into steps that contribute to the flow of value.
    • Steps such as Backlog, Planning, Development, Testing, Deployment, and Verification help identify where value is added and where inefficiencies occur.
    • These steps are different from granular tasks, which are the specific processes carried out within each step.
  4. The Confusion Between a Value Stream Mapping Step and a Process Mapping
    • One of the most common mistakes teams make is treating process mapping as value stream mapping.
    • Value Stream Mapping involves outlining the steps within a stage or phase of the Value Stream to identify delays, bottlenecks, and inefficiencies.
    • Process Mapping, on the other hand, is about detailing the specific activities within each step, such as coding, pull requests, code review, CI build, etc.

By addressing these four areas of confusion, teams can better align their understanding of Value Streams, ensuring Flow Metrics are applied correctly and effectively measured.

Value Stream Model

Value Stream Mapping

Process Mapping

Conclusion

When Agile work structures and Flow Items aren’t aligned, inefficiencies make measuring and improving value delivery with Flow Metrics harder. Linking Flow Items to the correct agile work item improves data quality and decision-making. Using a structured approach and best practices helps businesses maximize Flow Metrics and deliver results.

Bonus: Team Level OKRs

(Excerpt from Breaking Free from the Build Trap, Dec 25, 2024.)

OKRs align the team’s work with customer needs and organizational objectives. This alignment transforms sprints, epics, and initiatives from mere tasks into measurable milestones that drive meaningful business results.

OKRs bridge the gap between your team’s efforts and the outcomes that truly matter, encouraging a focus on value rather than speed. This mindset shift fosters intentional work and delivers impactful results.

Team Level OKRs tend to be either Initiatives or Epics.

Teams should define sprint goals based on outcomes, not tasks. Example: “Enhance system performance by improving response times by 5%” (outcome) versus “Complete three refactoring tickets” (task).

To develop a team-level OKR from a parent key result, you can use a method known as explicit alignment or cascading. This process transforms a higher-level key result into a focused objective for your team, ensuring clear alignment and purpose. Here’s an effective way to approach it:

  1. Define your desired outcome and ensure it aligns with a relevant Parent Key Result:
    Begin by reviewing the overarching OKRs at the company or department level. Identify a key result that aligns with your team’s responsibilities and can be directly influenced within your team’s scope.
  2. Transform the Key Result into an Objective:
    Reframe the parent key result as a clear objective for your team (the expected outcome). This objective will serve as the central focus of their efforts.
  3. Develop Supporting Key Results:
    Create 3-5 key results to help your team achieve this new objective. These should be specific, measurable, and aligned with the overall goal or outcome.
  4. Ensure Alignment:
    Make sure your team’s OKRs align with and support the higher-level objective they are based on. Set clear targets for each key result by defining what success looks like for your team about the parent key result. This will help keep your team focused and guide their efforts toward achieving the desired outcome.

References

  1. Project to Product: What Flows Through a Software Value Stream?, November 9, 2018 By Mik Kersten, https://blog.planview.com/what-flows-through-a-software-value-stream/

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Decoding the Metrics Maze: How Platform Marketing Fuels Confusion Between SEI, VSM, and Metrics

by

9 min read

A Landscape of Confusion

By 2025, the tech industry will be more data-driven than ever, with engineering teams and leaders relying on metrics-driven insights to improve software delivery performance. However, the rise of Software Engineering Intelligence (SEI) platforms, existing Value Stream Management (VSM) platforms, and engineering metrics solutions have created a new challenge: marketing confusion.

Platform vendors, eager to differentiate their offerings, often blur the lines between these categories, making it increasingly difficult for technology leaders to distinguish between tools designed for engineering visibility versus those aimed at full-value stream optimization. This confusion leads to misaligned expectations, ineffective investments, and ultimately, frustration when organizations realize they’ve purchased a solution that doesn’t align with their needs.

This article serves as a follow-up to my August 2024 article:

Since that article, the landscape has continued to evolve. SEI platforms have gained significant momentum, the DX Core 4 framework has been introduced, and VSM platforms are still in the conversation but with a shifting narrative.

Derek Holt, CEO of Digital.ai, has observed what he believes to be a major industry shift:

“While Value Stream Management continued to lose steam in 2024, we also saw the fast emergence of Software Engineering Intelligence (SEI) to take its place.” – Derek Holt, CEO of Digital.ai (SD Times)

However, other experts argue that VSM remains critical for aligning technology with business outcomes. Heather Spring, a senior Product Marketing expert, highlights the enduring value of VSM:

“VSM is more than a process improvement tool. It’s a framework for achieving measurable business outcomes.” – Heather Spring, Broadcom ValueOps (Broadcom Academy)

These contrasting viewpoints contribute to a growing problem:

  • Senior leaders struggle to distinguish between practices and platforms.
  • Different tools claim to offer “the future of software measurement,” but many serve only a narrow scope.
  • Organizations risk making misinformed investments based on incomplete narratives.

My Perspective as of February 2025

This article represents my point of view, given the current state of these technologies in early 2025. Over the past few years, I’ve observed significant shifts in how software measurement platforms are marketed, adopted, and integrated into organizations.

Importantly, this article does not dive into specific frameworks such as DORA, SPACE, Flow Metrics, or team sentiment and developer experience qualitative metrics. Instead, it focuses on the platforms that integrate these various metrics and how their marketing narratives have confused senior leaders unfamiliar with this space.

The Growing Demand for Data-Driven Insights

A few years back, DORA metrics gained much attention, and early tools focused on providing dashboards to track them. Over time, these tools evolved and rebranded as Software Engineering Intelligence (SEI) solutions.

SEI platforms have gained significant traction recently as organizations recognize the importance of developer efficiency, software delivery performance, and engineering operational health. These platforms provide granular insights into pull request cycle times, deployment frequencies, mean time to recovery (MTTR), and engineering throughput, giving leaders a clear picture of how efficiently software is being built and delivered.

At their core, SEI platforms are designed to improve engineering operations, helping teams identify delivery bottlenecks, optimize workflow efficiency, and measure team health. For organizations still struggling to improve operational efficiency within delivery, SEI platforms make perfect sense and provide immediate feedback on a team’s ability to consistently ship high-quality software.

However, SEI is not the same as Value Stream Management.

Understanding the Misconceptions Around SEI and VSM

The key difference between these platforms lies in their scope. While SEI focuses on engineering processes, VSM platforms aim to provide end-to-end visibility across the entire software development lifecycle—from ideation and discovery to delivery and operation. The challenge is that many platform vendors position SEI as interchangeable with VSM, when in reality, the two serve different yet complementary purposes.

This overlap often leads to misaligned expectations for companies adopting these tools. Organizations seeking deep engineering intelligence might mistakenly invest in a VSM platform. VSM platforms can be more expensive because they can gather and present data from all stages of the digital product lifecycle, and most vendors target the larger enterprise market. However, they may lack detailed data from the engineering delivery stage, or your organization may not be ready to handle this scope. Companies looking for full end-to-end visibility might purchase an SEI platform focusing only on software delivery, preventing them from improving efficiency in the other value stream stages.

I recommend using metrics that cover the entire Value Stream, but this might not be cost-effective for many companies. To avoid choosing the wrong platform, technology leaders should start by identifying their organization’s bottlenecks:

  • An SEI platform is likely the best investment if engineering teams struggle with delivery performance.
  • If the challenge extends beyond engineering into product management, discovery, and business alignment, VSM will become a stronger choice.

VSM Only Works If Other Departments Are Engaged

One of the biggest mistakes companies make when adopting VSM platforms is assuming that technology alone can drive the initiative. The reality is that unless other departments, such as marketing, sales, or business leadership, see the value in tracking their processes, a VSM approach will not deliver full business impact.

VSM investment becomes effective when organizations use it to:  

  • Track and improve discovery workflows, such as how product teams validate ideas before passing them to engineering.  
  • Interest in capturing how the marketing and sales teams collaborate to support the discovery phase of the value stream by capturing these processes.
  • Provide visibility into how cross-functional collaboration impacts the creation and delivery of digital products.

If your leadership and other departments discuss process visibility and workflow optimization, a VSM solution can drive enterprise-wide improvements in parallel with software delivery improvements. However, if the initiative is primarily driven by engineering, then SEI is the better starting point, allowing teams to optimize delivery before expanding to broader value stream visibility.

My Journey Evaluating These Platforms in 2022

Between 2022 and 2023, before the term Software Engineering Intelligence (SEI) became widely known, I carried out a detailed evaluation of platforms for my organization including:

  • Digital.ai
  • ServiceNow
  • Planview (then Tasktop Viz)
  • Jellyfish
  • Broadcom
  • LinearB
  • Plutora
  • Pluralsight Flow
  • Sleuth

Most of these platforms have improved since I first evaluated them. At the time, to the best of my knowledge, tools like LinearB, Sleuth, and Jellyfish had not yet embraced the term SEI. They were engineering analytics tools focused on measuring software delivery performance. Meanwhile, Tasktop, Digital.ai, Broadcom, and ServiceNow identified their offerings as Value Stream Management (VSM) platforms.

Given our organization’s transformation stage, I narrowed the choices down to two platforms:

  1. Tasktop Viz (now Planview Viz) – A strong VSM platform offering broad value stream insights but lacking delivery-stage granularity.
  2. LinearB – A strong delivery-focused platform providing deep engineering analytics but lacked visibility for ideation-to-delivery.

At the time, I saw clear trade-offs:

  • VSM platforms were valuable for tracking end-to-end flow but lacked deep delivery insights.
  • Delivery-focused platforms had engineering visibility but provided no insight into ideation or operations and support stages of the Value Stream.

In 2024, my preferred VSM platform acquired an SEI platform, confirming my earlier belief that larger VSM platforms without detailed delivery integration would eventually seek to expand their capabilities through acquisitions.

The Emergence of DX Core 4

Contributing to the ever-changing landscape and array of choices, a significant development is DX Core 4, a framework designed to unify existing developer productivity models. DX Core 4 brings together principles from DORA, SPACE, and DevEx, focusing on four key dimensions:

  • Speed – How quickly software moves through the system.
  • Effectiveness – The ability to deliver software that meets requirements.
  • Quality – Ensuring software meets standards while minimizing defects.
  • Impact – Measuring the business and customer impact of software delivery.

The intent behind DX Core 4 is to balance these metrics, preventing over-optimization in one area at the cost of another. GetDX’s announcement provides more details.

Breaking Down Marketing Myths

Myth 1: AI is Exclusive to SEI

The SEI Claim: SEI platforms are the future because they use AI for deep analytics and decision support, while VSM platforms do not.

The Reality: This is completely false. Leading VSM platforms, including Planview Viz and ServiceNow, have invested heavily in AI and generative AI-driven insights for deep data analysis, decision-making, and flow optimization.

SEI vs. VSM AI Capabilities

AI is not an SEI-exclusive feature. Instead, SEI and VSM integrate AI-driven analytics, SEI for engineering delivery metrics, and VSM for end-to-end business value flow across the organization.

Additionally, Planview’s Viz (copilot), Broadcom’s ValueOps (The Future of Value Stream Management Will Be Powered by AI), and others have integrated AI-driven workflow automation, tool integration, and predictive analytics, further demonstrating that AI capabilities are not exclusive to SEI.

Myth 2: SEI Covers the Full Value Stream

The SEI Claim: SEI platforms provide comprehensive visibility into software engineering performance.

The Reality: SEI platforms focus on the delivery stage of digital product development. They analyze developer productivity, team and operational efficiency, and software engineering health, but they do not track the full lifecycle of a digital product from ideation to operation. The SEI platform might be just what your organization needs at its current stage or context.

Comparing Scope: SEI vs. VSM

The Main Takeaway

The key takeaway in the SEI vs. VSM discussion isn’t which toolset is gaining momentum; it’s about scope. Don’t let marketing hype or opinions mislead you. While they can guide your decision, it’s crucial to understand the framework or label: SEI focuses on software delivery performance metrics within the build and deployment pipeline, while VSM spans the entire digital product lifecycle, discovery, delivery, operations, and support.

SEI tools offer limited insights into how efficiently code moves through development and deployment, but VSM goes further by asking: Are we delivering the right value efficiently across the entire product journey? When evaluating a VSM platform, consider both the quality of development and deployment metrics and the broader data they use to provide visibility across the value stream and organizational impact.

Rather than viewing SEI as a competitor to VSM, see it as a specialized tool for the delivery stage, while VSM ensures visibility, optimization, and continuous improvement across the entire value stream.

Choose the Right Metrics for Your Needs

Instead of asking, “Which platform is winning?” the better question is:

Which platform works best for your needs and provides the best visibility, whether for a specific part of your value stream or the entire one?

Organization and Engineering leaders should focus on what matters: selecting the right tools to address the correct problems. The question isn’t just about SEI vs. VSM. It’s about clearly understanding:

  • Where your organization’s bottlenecks exist
  • Who is driving the initiative
  • What level of visibility will drive the most impact

A few years ago, I started working with modern metrics like DORA. Since then, I’ve become a board member of the Value Stream Management Consortium, a champion for VSM implementation at my current organization, and an advocate for aligning software delivery metrics with business outcomes. This has given me the chance to explore the growing world of value stream management (VSM) and software engineering intelligence (SEI) platforms. Interestingly, a former colleague of mine is now a co-founder of one of these emerging platforms.

Vendors often use persuasive marketing to grab your attention and budget, but it’s important not to get caught up in the hype. Focus on your organization’s specific needs and the scope of the solutions offered. VSM and SEI platforms can differ greatly in features and cost, so finding the right fit means balancing your budget with your business priorities. Take the time to assess what truly matches your goals before making a decision.

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

Beyond outcome-focused metrics: Connecting Work to Outcomes

by

5 min read

In her recent article, Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025 1, Leah Brown from IT Revolution, an industry-leading resource on digital transformation strategies, emphasizes prioritizing real business value over purely technical outputs. She highlights that truly effective value measurement requires:

  • Clear alignment on strategic direction and goals
  • Regular communication of value across stakeholders
  • Built-in feedback loops to validate assumptions
  • Focus on outcomes over outputs
  • Willingness to adjust based on learning

This approach aligns with IT Revolution’s research, which has been instrumental in shaping modern software delivery practices. These principles align closely with my mission to bridge the gap between technology investments and business outcomes through better flow, business alignment, and leadership accountability.

A key challenge in many organizations is that software development and platform investments are often seen as black boxes, necessary costs disconnected from measurable business value. By structuring measurement around value streams and outcome-driven metrics, we can connect technology investments directly to business results and make the value of software delivery transparent.

Applying Value Stream Thinking to a Culture of Value Measurement

Shifting the organization’s focus to customer value streams is a key way to reinforce strategic alignment, feedback loops, and outcome-driven measurement.

When value streams are the core management approach:

  • Customers get the immediate benefit of priority at the organizational level – In addition to internal teams optimizing for efficiency, the entire organization prioritizes work that directly improves customer outcomes.
  • The organization becomes more responsive to customer needs and value creation, aligning outcomes over outputs. A value-driven operating model ensures that teams measure success not by what they produce but by how it improves customer experience, revenue, or retention.
  • Problems surface earlier, and solutions are faster and more sustainable. Value streams highlight bottlenecks and inefficiencies in delivering customer value while supporting built-in feedback loops, ensuring that delays, hand-offs, and friction points are made visible before they become significant issues.
  • Collaboration, continuous improvement, and problem-solving become natural outcomes – Instead of forcing teams into siloed KPIs, a value stream focus encourages alignment across departments, reducing hand-offs and friction, enabling faster decision-making, more iterative feedback, and fewer artificial constraints.
  • There is a clear and transparent connection between work and value – In many organizations, software teams are seen as cost centers rather than strategic enablers. When work is structured around value streams, there is greater transparency into how investments in software development and platforms contribute to business goals. This alignment reinforces regular communication of value across stakeholders.
  • All initiatives must be tied back to a customer or business metric. This principle directly supports outcome-driven measurement. By tying all work to business metrics, organizations avoid point optimizations (improving one team’s efficiency at the expense of customer value) and instead focus on work that improves a few critical metrics.
  • Cross-company cultural initiatives become easier to implement – Many organizations struggle with broad transformation efforts because they are optimized for vertical silos, not horizontal value delivery. Value stream management connects teams across functions, making it easier to align priorities, drive enterprise-wide change, and improve strategic execution.
  • Bureaucracy and process inefficiencies become visible – One of the most significant benefits of value stream-based measurement is that it exposes where excessive approvals, dependencies, and misaligned goals slow delivery. By tracking work across the value stream, organizations can see where bureaucracy blocks flow and make data-driven improvements.

Value Streams & Flow Metrics: Unclogging the Arteries of an Organization

In Value Stream Management conversations, the highway analogy regarding the greater volume on a highway, the more restricted cars travel (referring to work in progress or WIP), or if roadwork is slowing the flow is common (friction). Recently, I came across an analogy comparing Value Stream Management to clogged arteries. Most organizations operate like clogged arteries. Excessive hand-offs, approval processes, and misaligned priorities block value streams. Instead of measuring and improving flow, they optimize for vertical efficiency in isolated teams, much like focusing on individual organs rather than blood circulation.

  • The heart keeps blood flowing freely in a healthy body, ensuring oxygen and nutrients reach every part of the system.
  • Value Stream Management keeps work flowing freely in a healthy organization, ensuring value reaches customers and reducing delays.

However, many organizations suffer from congested workflows, unnecessary approvals, long hand-offs, and fragmented ownership, like arteries clogged with plaque leading to:

  • Work stalling in queues instead of moving efficiently.
  • Teams focus on local optimizations rather than system-wide flow.
  • Decision-making being slowed by too much bureaucracy.
  • Business leaders are unable to see where the real problems are.

Instead of waiting for a heart attack (a major failure or missed market opportunity), organizations should treat flow efficiency as a leading indicator of business health. Just as doctors track blood pressure and cholesterol to prevent heart disease, organizations should track Flow Metrics to avoid workflow breakdowns.

Value Streams as the Foundation of a Culture of Value Measurement

Building a true culture of value measurement requires structuring the entire organization around outcomes and customer value streams, not internal projects or siloed optimizations. Organizations can reinforce a culture of Outcome focus and Value Measurement using Value Stream Management.

  • Start with Clear Alignment on Strategic Direction – Each value stream team should define or be clear on the expected outcomes before starting work.
  • Regularly Communicate Value Across Stakeholders – Track progress using OKRs and periodic metric reports. Consistently evaluate performance to highlight progress, small achievements, or course corrections.
  • Implement Feedback Loops to Validate Assumptions – Capture and reflect on Flow, DORA, and related Metrics across the entire value stream, not just engineering velocity.
  • Focus on Outcomes, Not Just Outputs – Use Value Stream Thinking to ensure teams optimize for business results rather than just completing tasks.
  • Be Willing to Adjust Based on Learning – If a team’s work isn’t improving a key customer metric, be willing to pivot and shift priorities based on real-world feedback.
  • Make Technology Value Visible – Stop treating software and platform engineering as an invisible backend function. Instead, connect technology investments directly to business goals like revenue, customer retention, and agility.

Want to Go Deeper?

For further reading, check out these articles:

Metrics

Let’s continue the conversation: how is your organization shifting from output tracking to actual business impact using value streams?

Poking Holes

I invite your perspective on my posts. What are your thoughts?.

Let’s talk: [email protected]

References

  1. Measuring What Matters: Using Outcome-Focused Metrics to Build High-Performing Teams in 2025, Leah Brown, IT Revolution, https://itrevolution.com/articles/measuring-what-matters-using-outcome-focused-metrics-to-build-high-performing-teams-in-2025/

Managing Technical Debt: Interest Rates, Impact, and Continuous Payments

by

5 min read

In my earlier article, Advocating for Refactoring Prioritization in the Context of Business Goals, I discussed the importance of aligning refactoring efforts with business objectives. As I continue working with cross-functional software delivery teams, a persistent challenge remains: How do we prioritize technical debt alongside feature work?

One of the challenges many of us experience across software delivery teams is balancing technical debt work with feature development, defect resolution, and risk mitigation. Too often, technical debt becomes a “later problem,” a looming burden that teams only address during rare, large-scale cleanups. This reactive approach is costly, time-consuming, and disruptive. What if teams treated refactoring like paying down a car loan or mortgage instead? By making continuous, small payments, teams can manage their technical debt effectively, avoid major disruptions, and maintain a healthier codebase.

This topic resurfaced for me while listening to Martin Fowler’s recent conversation on a podcast on technical debt1. Fowler discussed how the metaphor of technical debt as financial debt helps teams decide when to “pay interest” (live with the consequences of cruft) versus when to “pay down the principal” (refactor and improve maintainability). He emphasized that the real power of this metaphor lies in evaluating the cost of inaction, understanding how much harder it becomes to work within a debt-ridden system, and deciding when the trade-off is no longer sustainable.

One idea that resonated with me is the importance of treating technical debt like financial debt in a more structured way. Not all debt is equal. Some accrue high interest (actively slowing down teams and introducing defects), while other debts have low interest (minor inefficiencies that don’t immediately impact delivery).

As a software engineer and leader, I strongly support a simple approach many in the industry advocate: regularly addressing small amounts of technical debt instead of letting it build up into a bigger problem. As Martin Fowler warns about letting cruft pile up, teams must proactively incorporate refactoring into their daily work. Instead of waiting for large-scale cleanup efforts, we should treat refactoring like making the minimum payments on a loan, ensuring that technical debt never compounds to an unmanageable state.

Technical Debt as a Loan: The Power of Minimum Payments

To extend the metaphor of technical debt as financial debt, let’s consider how we approach paying off a loan:

  • Minimum payments: Even if you can’t pay off your entire loan right now, making regular minimum payments ensures the debt doesn’t spiral out of control.
  • Lump sum payments: Occasionally, you might have the opportunity to pay down a large chunk of principal, significantly reducing future interest.

When applied to software development, these concepts offer a useful lens for managing technical debt:

  • Minimum payments: Every time a team touches a section of code, they should commit to improving it incrementally, whether through refactoring, improving test coverage, or simplifying logic. Minimum payments are akin to pulling small weeds in a garden whenever you see them, preventing them from growing into a tangled mess.
  • Lump sum payments: Occasionally, teams may need to dedicate focused effort to resolving high-interest debt, such as a major architectural refactor or addressing systemic issues in a critical module.

By regularly making small improvements, teams can prevent technical debt from accumulating to the point where it requires costly interventions.

Integrating Minimum Payments into Daily Work

Refactoring should not be a separate project or deferred until a “later” that rarely arrives. Instead, it should be a continuous part of the development process woven into every task. Here’s how teams can make this mindset part of their daily work:

  1. Adopt the “Boy Scout Rule”: Leave the codebase better than you found it. Each time a team touches a file, they should look for opportunities to simplify or improve it, even if it’s just removing a small piece of cruft or adding a meaningful test.
  2. Refactor within feature work: When building a new feature, allocate time to clean up the surrounding code. For example, if adding functionality to a poorly written class, take the opportunity to refactor it into a more maintainable structure.
  3. Set aside capacity for improvement: As teams plan for feature work, defects, and risks, they should explicitly allocate capacity for technical debt. Allocating capacity doesn’t always mean large refactoring efforts. It could mean committing to small, meaningful improvements during sprint planning.
  4. Make refactoring visible: Use tools like Jira or technical debt registries to track and prioritize technical debt. By making this work visible, teams can demonstrate its value and ensure it’s considered during planning.

These practices ensure that teams always make minimum payments on their technical debt, reducing the risk of accumulation.

Balancing Technical Debt and Business Outcomes

While continuous payments are vital, teams must prioritize technical debt work based on its impact. Just as interest rates guide financial decisions, teams can evaluate technical debt’s “interest rate” to decide when and where to focus their efforts.

Here’s how teams can assess technical debt:

  1. Interest rate: What is the cost of maintaining this debt? Does it slow development, increase defect rates, or create deployment risks?
  2. Impact of repayment: What business or customer outcomes will this debt improve? For example, will it accelerate feature delivery or enhance customer reliability?
  3. Visibility: How often does this debt surface? If it’s in a rarely used module, it may be a lower priority than debt in a core system.

For example:

  • A low-interest debt might involve minor inefficiencies in logging frameworks, which can be deprioritized in favor of high-impact features.
  • A high-interest debt, such as a tightly coupled architecture that slows feature delivery, should take priority because it can significantly impact productivity and customer outcomes.

These criteria allow teams to decide how much effort to allocate to technical debt versus other priorities.

Teaching Advocacy for Technical Debt

One of the challenges I’ve seen is that technical leads and managers often struggle to advocate for technical debt. Product owners naturally excel at framing features in terms of business outcomes, such as increased revenue or customer satisfaction. Technical leads must develop a similar skill: speaking the business language to articulate the value of addressing technical debt.

Here are some strategies for building that advocacy:

  1. Focus on outcomes, not processes: Instead of saying, “We need to refactor this code,” say, “Refactoring will reduce our lead time by 20%, enabling us to deliver features faster.”
  2. Leverage metrics: Quantify the impact of technical debt using cycle time, defect rates, or other engineering metrics.
  3. Collaborate with product owners: Work with product owners to align resolving technical debt with roadmap goals. For example, focus on fixing critical debt before major feature launches to allow enough time for resolution and keep the efforts on track.

Technical debt management is not about waiting for a perfect moment to act. It’s about weaving continuous improvement into the fabric of daily work, balancing short-term business goals with long-term sustainability. With the right mindset and advocacy, we can ensure that technical excellence and business outcomes go hand in hand.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: [email protected]

Advocating for Refactoring: Prioritization in the Context of Business Goals

by

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]