How do Agile teams know if they are successful? There is a large collection of metrics that many experts suggest to evaluate the performance of Agile teams, many of which you are likely already using today. I would like to share a few of my personal favorites with you and also explain why I like them. Feel free to borrow these if you think your team can apply them!
|Cycle time||Efficiency, Throughput||Amount of time required to complete a unit of work from the time that work has begun.|
|Defect rate||Quality||Amount of quality issues as a factor of time.|
|Mean time to repair||Efficiency||Amount of tire required to resolve a defect or restore a service to normal operation.|
|Delivery frequency||Throughput||Quantity of deliveries to the customer.|
|Team morale||Engagement||Level of engagement for the team.|
|Customer satisfaction||Engagement||Level of happiness from the customer perspective.|
Let’s take a closer look at each of these and dive into why I like the metrics. If you disagree, that’s entirely understandable! Due to the diverse nature of the organizations in the world today, environmental and business objectives tend to heavily influence the focus areas for each organization, so I would expect that you might value some metrics more than someone else.
Cycle time – I tend to recommend cycle time to most Agile teams because this metric provides a lot of useful insights into how the team is functioning. Cycle time is similar to the speedometer or the GPS tracker inside your car – it provides you with how well your machine (i.e. your team) is running, and also provides a forecast to how the team may perform in the near future based on current conditions. In my opinion, any Agile team must have a clear understanding of their cycle time if it aspires to reach “high-performing” status.
Defect rate – Simply producing a lot of “stuff” and shipping it to the customers does not automatically mean success; quality is usual important to most teams. Defect rate provides an indication of the quality of the work that the team is producing, which also serves as a predictor for rework; a less-than-desirable defect rate will usually lead to higher rework, hence degrading the team’s ability to produce valuable features for the customer.
Mean time to repair – The team’s ability to recover from a failure is a very telling indicator of the team’s problem-solving capability. While errors/mishaps are expected, how the team responds to unforeseen issues will determine its ability to drive value in the future.
Delivery frequency – I like this metric because it demonstrates a few subtle details about the team’s ability to build and sustain a sound solution architecture and infrastructure. The more quickly a team can deliver a solution, the more likely that the solution architecture is solid. Also, being able to deliver quickly will generally mean that the team can also recover quickly since if the team does not have such a capability, it will not be able to maintain a high delivery frequency.
Team morale and customer satisfaction – I grouped these two metrics together because they are both “non-technical” in nature, yet they are both highly important to a team’s success. Success, however small, builds and cultivates engagement for both the team members as well as the customer. Hence, these two measures are tightly bound together; in my experience, it is quite rare for one to be high yet the other to be low because in most situations, the team feedback off of the customer sentiments and vice versa. Following in the essence of close customer collaboration, Agile teams should understand the importance of building and maintaining an effective relationship with customers in order to achieve the desired successes.
If you read this far, you may have realized something missing from my list – velocity is not here?! You may be wondering why this popular metric is left out of my list. Here’s my thinking – velocity is a measure of the volume of work (or quantity of work) delivered by the team within a given timeframe. Based on its definition, there is no association of volume to value, which means that how much work the team produces does not necessarily correlate to positive outcomes. Furthermore, this measure is highly subjective since most teams use the often-confusing construct of Story Points to measure the amount of work completed; this is yet another topic that is often debated amongst the Agile community. Hence, I have decided to leave this measure off my list. You will likely encounter other Agile practitioners who are fully-committed to velocity and swears by them. If this works for that team or organization, then that’s a great thing for their environment.
In my opinion, I feel that most organizations value at least one of the seven metrics that I have shared. If your team is new to Agile, I would recommend choosing two metrics as a starting point and then adjust accordingly based on what your organization cares about. Inspection and adaptation are keys to your success.