Break Free from Agile Pt. 3: Building Lasting Value through Outcomes

Part 3: Building Lasting Value through Outcomes

In Part 1, we established that the current implementation of Agile stripped away the original intent of the creators.

In Part 2, we discussed common inefficiencies within development teams

Now we will focus on the structure for an alternative to modernize development and help companies creating software with lasting value. Central to this is bringing outcome-focused evaluation to every product team member.

To ensure alignment with the "why" of priorities and enable every team member to devise creative solutions for customer and business issues, it's crucial to establish goals not only among project managers but also developers, designers, and product managers.

We should construct goals based on clear data and success criteria, and converge across teams based on a hierarchy of relationships. In short, every team’s priorities relate to each other through the product.

• The product sets the ‘North Star Metric’ that brings teams together over multiple planning cycles.
• As team’s structure themselves around parts of the product, Capability or Team-based ‘Success Metrics’ provide clear goals to anchor prioritization.
• Finally, ‘Proxy Metrics’ provides granular data points that aggregate over time to move the team’s success criteria. This allows for the team to make tradeoffs, embrace challenges with uncertainty but higher payoff, and tackle customer facing problems in a cohesive manner.

Valuation mechanisms, how much something costs and how it will have to perform to generate value, enable priority transparency to all engineering, product, design and front office teams. The faster you deliver on a MVP, the faster you can determine worth, and increase confidence and future investment priority.

To operate well, a common data structure is required to support these workflows.

• A ticket is a statement of product opportunity - not what to do, just the problem or request from the customer’s point of view, which can inherit attributes of the customer (size, revenue, impact, etc.)
• Enhancements, which link to tickets, propose solutions to solve the problem and link to the existing features they improve. Tickets help support the valuation of the enhancement, and teams will go through phases of amassing, clustering, and aggregating tickets to capture every opportunity and the supporting evidence holistically.
• Issues related to the enhancement detail the engineering requirements to deliver the solution and help assign a cost. This is equivalent to a ‘no less than’ question as to effort, vs. ‘no more than’. The latter promotes padding estimates, and the former helps facilitate a more meaningful understanding of cost and avenues to deliver on a MVP for early validation.
• All of this aggregate into a score (value-cost), that can bring structure to any prioritization discussion.

The benefits of this simple yet powerful structure are the removal of bias, an emphasis on estimating minimum effort vs. maximum padding, and the ability to weight small experiments and bug fixes equally, against larger architectural or complex feature requests.

Execution

The power of this model comes from deconstructing complex processes in favor of more intuitive and integrated workflows. Instead of antiquated terms requiring domain knowledge, a state machine defines prioritized work into Now, Next, and Later.

• Now = What is both planned and being executed on which is derived from connected applications (e.g. Git keystrokes). By capturing Now as a reflection of active development, a real-time meter can help teams understand while changes within a sprint may occur. We can evaluate them without overly rigid constructs.
• Next = A prioritized, scoped estimate of what we will work on within a following sprint.
• Later = A backlog of issues, expected to be committed to in the milestone for shared visibility.
• By combining human-based scoring with machine-based scoring, we can assign value and rank to new customer feedback and programmatically determine how it fits into the overall priorities.

When moving Issues to the Next stage, the conventional approach is to estimate the effort or break down the work further to ensure completion within a specific time interval. However, instead of evaluating a work item based on a "no more than" estimate, teams should request a "no less than" estimate.

Proposing this value provides developers with greater comfort by removing the negative associations of surpassing an estimate and the constant requests for updates on incomplete work. This straightforward modification reduces overhead and distractions, which can cause teams to overemphasize effort estimates.

The last step in implementing this process is to establish a culture that fosters adaptation. It's essential to cultivate an adaptive mindset and provide developers with the freedom to experiment and iterate towards the optimal solution, as we cannot teach adaptation.

Auto-ranking aids in prioritizing future investment, while small experiments facilitate the validation or invalidation of hypotheses, allowing teams to iterate quickly and confirm assumptions. By encouraging creators to embrace adaptation, they can maintain product and customer centricity while building and iterating towards a goal.

Roadmapping

Companies are making grand efforts to support future claims that rarely stand the test of time when roadmapping today. An enhancement based model simplifies this by enforcing a level of flexibility into priorities. Just as we break down Issues into Now, Next, and Later to give a team foresight into the current plan over the next 2 sprints, roadmap items beyond that assume a growing lack of confidence the farther out they project.

We may detour the product direction based on both internal and external factors if we use a tree riddled with inflection points instead of a Linear Perceptron Learning Algorithm (PLA) for better visualization.

Those few people quickly render their roadmaps stale by sharing them. Product priorities get mixed with engineering priorities, then tested against customer demands, finally to be foiled by resource allocation.

To improve the chances of effectively using the initial investment in roadmap planning, both customers and developers should make sure that the roadmapping tool closely aligns with the current features and capabilities that are important to the customer, as well as with the services that are being built and maintained by the developer.

Summary

The constructs to support product development and execution require a customer and product centric platform for work prioritization, tracking, and evaluation. We must connect a modern product development process to the customer and the metrics monitored in real-time to avoid over indexing on management overhead.

DevRev offers a solution that enables makers to do their best work. By creating a flexible framework for planning via Now, Next, Later, for estimating effort, and for scoring work; DevRev enables developers to embrace a process that will benefit their workflows through AI, Just-In-Time prioritization, and a culture of adaptation.

Challenging Agile isn’t a revolution but merely an evolution of the idea laid out nearly thirty years ago by the inventors of ‘Agile’, while incorporating and integrating it into the modern real-time product toolset.