Measuring Team Performance in Agile Software Development

When a measure becomes a goal, it ceases to be good. — Kent Beck

Agile is the set of principles software teams use to deliver the highest value product to the customer in the shortest amount of time. Agile processes include sprints that allow teams to identify and put in place features with the most market potential.

Measuring performance in software is complex — partly because, unlike manufacturing, the inventory is invisible. The key to successful change is measuring and understanding the right things with a focus on capabilities, not maturity. Delivery lead times and deployment frequency are both software delivery performance tempo measures. Measure productivity by calculating the number of deploys per day per developer.

Velocity is a relative and team-dependent measure, not an absolute one. Velocity isn’t about measuring the team. It is about having a coarse-grained forecast. Velocity is the rate at which a team delivers value to the customer. A team that completes many tasks but delivers no value to the customer should have zero Velocity. Velocity is a measurement, not a goal.

The project is still ongoing when all the stories are implemented. The project is over when there are no more stories in the deck worth implementing. Complexity is measure base on all the factors that can change an outcome if something takes more time and is more complex. Only the points for stories that have passed their acceptance tests are recorded on these charts. The burn-down slope predicts the date for the next major milestone. If we see a positive slope, it likely does not mean the team is going faster. If the velocity chart shows a consistent negative slope, the most likely cause is the quality of the code. Focus on outcomes, not output.

Constant Velocity is a simple metric to tell if a code base is good enough. Constant Velocity suggests that the code is easy to change. When the team faces a change in the code base is as easy as last time. In any application, with time, developers will find new friction points that will prevent them from moving forward. The friction is often visible in the team’s Velocity.

Lead time is a measure of how fast work can be completed. Lead time is the time it takes to go from a customer requesting the request to be satisfied. Lead time is the time it takes to go from code committed to code running in production.

Cycle time measures the actual team’s Velocity. It measures the time it takes from working on a feature until it has been shipped and provides customer value. A coupled system maintains long Cycle times because many modules have to be changed in unison.

Measurement is required to help improve a team’s software development processes. Cycle time through data about PRs, code reviews, and languages is familiar but difficult to access.

Code Climate’s Velocity is a new code metric tool to measure cycle time. It uses factual data from GitHub to help the team find bottlenecks. Help drive continuous improvement, and promote data-backed understanding. Unfortunately, Coding meta-data can be abused or gamed. We are determined to use this information for good, to help engineers grow, and to prevent misuse and misunderstanding of this data. At the same time, it can also be used to reduce bias, help us work together, and support our goals.

Velocity cannot capture engineers’ work outside of coding and related activities. Data is a great starting point for a conversation, but it only tells part of the story. Code Climate’s Velocity makes accessing, visualizing, and understanding coding meta-data easier and accessible to everyone.

[¹]: Nicole Forsgren, Jez Humble, Gene Kim(2018): (Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)

[²]: Robert Martin(2019): (Clean Agile: Back to Basics (Robert C. Martin Series))