Fresh from the ALM Forum in Seattle, Washington, I’m going to share with you the only metrics that matter.
It feels a bit like cheating—like ordering apple pie for dinner, or eating shelled pistachios—but I’m going to do it anyway.
The ALM Forum is a three-day gathering of software professionals dedicated to the dark arts of software lifecycle management. These are the project leaders, scrum masters, agile coaches and IT architects who care deeply about the meta-data of software development, and who live their professional lives at the intersection of software development and organizational change consulting.
As you can imagine, metrics are never in short supply at this conference. Pretty much every presentation—whether from Etsy, Bank of America, or Ancestry.com—usually involves at least one “before” and “after” chart that displays the impact of some stimulus—a change in process, tools or organizational structure—and often, a mix of all three.
So after three days of attending excellent presentations that included hundreds of metrics, here are my candidates for the only metrics that matter. They come in two categories: technology and (in my next post) organization.
First, technology. And folks, it’s all about reducing mean time to feedback, at least according to Steven Borg, a co-founder and principal ALM consultant of Northwest Cadence.
We all know what it’s like to solve a complex problem, whether it is solving a mathematical equation, building a new software feature, or resolving the form and function of a kitchen remodel.
When we are in the problem-solving zone, we study the problem, break it down into smaller, more manageable parts and even create models of the problem space. We are keenly aware of multiple levels of information, context and interdependencies.
But this deep contextual understanding comes with an expiration date. For most of us, our brains are just too porous to maintain this deep contextual knowledge after we’ve turned our attention to something else. That’s why there is such a huge difference between getting feedback in an hour, a week, or a month. If we get feedback when the problem is fresh in our mind, then we can quickly and efficiently respond.
If we get that feedback weeks later, it may as well have gone to a different person with no prior knowledge of the problem. Like the Bill Murray character in Groundhog Day, we are destined to painstakingly recreate our understanding of the problem all over again.
Multiply this by hundreds of discrete tasks and hand-offs, and you can quickly see how reducing mean time to feedback becomes a transformative organizational metric. According to Borg, teams that use mean time to feedback as their guiding principle will naturally evolve their organization over time to become more agile.
They will break the problem down into smaller vertical slices, fast-track internal feedback loops, automate testing, deployment and whatever else can be automated, deploy working solutions more quickly, and accelerate external feedback. It’s a North Star for any agile transformation.
From concept to delivery, the most important area to reduce mean time to feedback is (of course) customer validation. The quicker we can get prototypes or working software into the hands of our customers, the faster we can get feedback in time to make a difference in the marketplace.
Next, I’ll explore the only metric that matters for building high-performance organizations.
If you liked this article, please consider this your personal invitation to join us at PTC Live Global ALM Track and Forum, this June in Boston, where we’ll be exploring all things ALM, tuned to the unique needs of manufacturers.