Making the decision to move to an agile environment is tough enough, but opting to stay the course when agile gets difficult is even harder. In fact, it isn’t uncommon for companies to revert back to what they used to do; it is easier.
Like anything, determining whether agile is working is impossible if you’re not measuring for success. Likewise, it’s easy enough to think you’ve adapted enough of the “agile culture”, without tracking actual output and change. But most people who fail at adapting agile in their work environment do so because they haven’t tracked their successes.
So, why did you switch to agile anyway? The promise is big – reducing risk across the business and delivering results quicker and more efficiently, which results in greater customer satisfaction. Agile means that things change, but that you (all of you!) have to actually do the work. Talking about change and actually changing are two very different things, which is how these metrics will help you determine whether you’re actually changing to be more agile.
Measuring Agile Success
Metrics have a bad reputation, most of which is unwarranted. One sticking point? Choosing which metrics mean success for you.
There are a lot of ways to measure input and output, speed and efficiency, process improvement, and customer satisfaction, so which ones are most important? It’s less about which ones are the most important, as many measures similar things in different ways, but which are best for your team:
- Which metrics resonate the most?
- Which metrics make the most sense for your business?
- Which metrics can be tied to your overall KPIs?
The following sections provide an overview on product, process, and business success.
Turning to agile is supposed to make it easier and more efficient to reach a finished product. Agile relies on pre-determined sets of time, commonly a series of two-week sprints, and the team sets a goal of what to accomplish within each two-week sprint that will set them up to finish the product over the whole series of sprints. A common agile approach is that the product goals can shift over the series of sprints, but the project scope should not be changed in the middle of a single sprint.
Agile metrics, then, can tell you exactly where your development process is improving – or not.
The biggest, most popular way to track success is on-time delivery, but that metric may come a little too late. Here are common ways to track and achieve “done” while working towards the finish line:
- Sprint burndown, which tracks how much work the team has completed within a single sprint in comparison to what the team said they’d accomplish. Constantly finishing the work before sprints’ end means your team may not be taking on enough work, whereas rarely completing what you set out to do is a sign that you’re overcommitting.
- Version burndown, which is similar to a spring burndown but tracks progress over several or all sprints (epics), not just a single sprint. This metric can help determine whether you’re making zero progress or if the scope is changing too much or too frequently for meaningful work to be completed.
- Cumulative flow diagram, which tracks the workflow across all teammates involved. This is important to see who blazes through work and who is stuck on a problem, which can allow more teamwork to accomplish the sprint’s goals.
- Defects, which shows current problems and bugs that exist. Tracking these helps determine how much current time you can or should dedicate to address defects during development or whether you should push some off to a post-release fixing or saving certain defects for future releases.
The goals of agile are clear – efficient, speedy deliver that results in customer satisfaction – but the how is trickier. How do you improve? How do you get faster? How do you get more efficient? The answer lies in continuous improvement. If you’re seeking to implement an agile culture, then the team and management must support continuous improvement.
Here are two ways to track whether your process is actually improving:
- Control chart. Though this chart can be used in tandem with measuring “done”, a control chart shows the progress of individual pieces or components. This is useful because it immediately reflects whether your tweaks and changes (being agile) are actually helping, hindering, or having no result on the work.
- Velocity, which tracks the average amount of work over a sprint. Also useful in measuring for “done”, agile experts also know that tracking velocity over time confirms whether a particular change actually improved your process.
Of course, a finished project isn’t enough. Your entire development system may be agile but if your clients or customers aren’t satisfied with the working and final products, what’s the point of it all? Only business metrics can tell you whether your products are meeting the client’s or market need for it.
The best way to track this is to engage your customers in several ways and at different points of the process. Metrics like the ubiquitous net promoter score (NPS), sales figures, and stats that consider usage or support calls versus delivered features are essential to gauging whether successfully implementing agile culture also successfully improves your business – that’s the whole point.