Does Agile Really Work? 3 Ways to Validate Agile

Sure, going Agile is trendy. Sure, it’s the thing to do right now, especially if you’re developing software. But if Agile seems to be failing for your unique business and goals, then being in “the in crowd” won’t matter, will it?

Looking at the situation from a C-suite perspective, decision makers absolutely must be able to justify the investment of time, energy and other resources required to make an Agile transformation work if they’re going to support it over the long term. That’s why it’s important for Agile practitioners to keep an eye on specific metrics that actually help answer the question “does Agile really work?”

Here are three ways to validate Agile using metrics you can easily locate and maintain, and a bonus metric that everyone in your organization should be keeping track of:

1. Improve Predictability

How accurately can your Agile productivity be predicted on a team, project and portfolio level?

Predictability is important from a cost and a resource allocation perspective since budgets and schedules are based on workflow and completion of assignments according to plan. Two areas of predictability to begin researching and keeping track of are delivery dates and delivery content.

Delivery Dates

It may be possible to meet a poorly predicted delivery date, but it’s not in the best interest of products, team members or customers. To get started predicting delivery dates, take a look back at previous sprints and epics to determine how accurate the delivery estimates were in comparison to what actually occurred. Extrapolate out to similar future sprints to determine if those estimates can be reasonably adjusted to make the delivery date more predictable over time.

Delivery Content

In the process of struggling to meet a delivery date, stories and requirements may be altered or removed for the sake of time. Product owners can also introduce changes to the project mid-sprint, affecting the end result dramatically in some cases. Review how much the content requirements for a sprint change from estimates to completion and try to determine what caused the changes, who benefited from the changes, and whether changes can be more accurately.

2. Tighten Reliability

How reliable are the building blocks of your Agile projects (i.e., estimates and requirements)? The answer impacts all the teams and departments involved in supporting or carrying out Agile projects. Reliability also has a bearing on intangible aspects of how well Agile is working within an organization, such as interdepartmental friction or frustration or cultural issues that underlie other problems.

Estimates

Accurately predicting delivery dates and content of an Agile sprint can save valuable time and money, and even reduce stress. By reviewing past performance of estimates versus what actually occurred on the project, you should be able to identify constant variances – situations that come up repeatedly or constantly to cause estimates to fail. This insight can improve estimates incrementally as each sprint is planned, carried out, and reviewed, and it can even help you refine the product backlog in order to more effectively estimate the next round of sprints.

Requirements

Directly tied to the predictability of delivery content, the reliability of requirements as set out in the initial estimates is a crucial piece of the Agile validation puzzle, and one that product owners need to be especially interested in. Why are stories changing from one sprint to the next? Has there been significant feedback from customers, leading to improvements in the story requirements? Or were the original requirements allowed to go to production with foreseeable errors? Reviewing past performance in this area will help product owners approach future sprints with a higher level of consistency in crafting requirements.

3. Focus on Quality

High quality should be everyone’s goal, but sometimes quality is sacrificed for the sake of meeting other goals such as delivery time. Don’t fall into this trap.

Initial Quality

No one involved in an Agile project should be shooting for perfection in any given sprint. Perfection is very expensive, very slow, and often a sign of errors in your testing procedures. Instead, the goal should be to identify as many high-priority (mission-critical) defects as possible prior to release, and to properly prioritize and respond to post-release defects appropriately. Tracking defects on a timeline with prioritization included will help put this metric in perspective.

Cost of Defect Resolution

Once defects are identified, whether pre- or post-release, how efficiently they are addressed will have an impact on ROI. Generally, prevention is cheaper and more effective than resolving defects post-release. Begin to track defects with the goal in mind of moving the detection and resolution process pre-release whenever possible.

The Ultimate Metric: Customer Satisfaction

Above and beyond all these other means of validating Agile is the ultimate metric that every single person in your organization should be concerned with: how happy is our customer?

Unlike many other potential ways to track Agile success, customer satisfaction can be used across Agile teams, across Agile projects, and up to the portfolio level. It’s important to put together a custom set of metrics that track what is actually important to your unique customer and use those as the benchmark when reviewing all other metrics discussed here.

For more in-depth discussion of validating Agile, you’ll no doubt enjoy our webinar, Validating and Monitoring Performance Metrics.