The Measure Of High-Performance Software Teams
“How can one objectively measure the performance of a team?” is a question that came up recently in a geek talk with a fellow Austin-based technologist.
He mentioned that he wanted to encourage his teammates to work remotely more often. However, he needed to prove to his stakeholders that such practice wouldn’t negatively impact his team’s productivity.
As someone who has been building software and managing teams for many years, I have been exposed to a variety of different software development processes. More so, I have taken an interest in the subject and spent time studying the theory behind several methodologies (e.g. waterfall, [Rational] Unified Process, XP, SCRUM, Kanban) and related practices and certifications (e.g. PMI, CMMi, etc.). With this background, I thought I’d be able to offer a definitive answer on the spot, but, instead, I had to think.
Not a Manufacturing Metric
Objective productivity metrics have been successfully used in manufacturing. Manufacturing processes are highly standardized and productivity there can be rated based on inputs and outputs. Analogies between manufacturing and software engineering are common, but they aren’t necessarily accurate.
Unlike manufacturing, design and engineering processes need to be highly contextual and adaptable to be good — for that reason, any metric will only make sense in context and industry benchmarking isn’t actually possible.
Not the Ideal Agile Measure
Good engineering processes prioritize:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
As many will recognize, these words are from the Agile Manifesto. This is what gave origin to the Agile Movement and modern agile methodologies such as SCRUM.
The Agile Manifesto also suggests that “working software is the primary measure of progress.” That could very well be the metric I had been looking for. However, in practice, the notion of working software is difficult to grasp and to quantify for an audience with varying backgrounds.
Consensus
The answer, in the end, isn’t in either extreme.
I recommend that teams resist the impulse to adopt generally accepted metrics without questioning. Instead, they should take the time to evaluate options and agree by consensus on metrics that:
- Team members are comfortable tracking
- Communicate progress to team members and stakeholders alike
It is the team’s responsibility to distil a small number of simple metrics that make sense in their context of industry, company or project, and for their chosen process.
More important than knowing an absolute value for a metric is being able to track it over time and manage trends. For that, it’s vital to fix as many variables as possible (e.g. team size, time between measurements, etc.).
In the end, there isn’t a universal number that defines high-performance teams. There are many possible numbers, however, to tell when performance is on the right path and improving. Technically, one would have reached their peak performance when the metric of choice is maxed out. Don’t trust that such ceiling exists. When you think you can no longer improve performance, it’s possibly time to reconsider how you measure it.
