Metrics are hard: Choosing them is hard, gathering them is hard, getting anyone to look at them is hard. What about getting people who have looked at them to use them to make decisions? Yep, hard.

At the same time, organizations in the midst of large-scale transformations know how important they are. An objective measure of whether what we’re doing is working? Count me in! Industry benchmarks? Yes please! Customer behavior? Give me all you got.

The Big Boss wants to know whether it’s actually helping with your P&L. Unfortunately it’s very hard to draw a direct line in the early stages of an agile transformation, between new teaming practices and the bottom line of your organization. 

For these reasons, I wanted to share the one single metric that, if I had to pick, I would ask any agile transformation steering team to begin with. I call this The Magic Metric:

No. of internal teams getting feedback on real working product from end users in the past 28 days.

The Magic Metric encapsulates several key features of an agile organization:

• Teams as atomic unit of agility
• End user centricity
• Openness to fail and to learn
• Incremental and iterative delivery
• A cadenced rhythm to regular operations
• Leaders holding space for teams to make decisions and ship product quickly

Most importantly, the Magic Metric requires a mindset shift in how to operate effectively when the answers are uncertain.

Ok, but why “teams?”

A few reasons why we specify the number of teams. First of all it requires the organization to think carefully about what a team is. A focus on the number of times teams have received feedback may encourage simply shipping features. Likewise, the number of end users they’ve got feedback from may also encourage releasing the product too wide too fast.

What is "working product"?

Prototypes and sketches have their uses, but working product is something that an end user can see and feel and interactive. It may not be complete, but it is something they can help them identify what they like, or do not like. This diagram helps explain what we mean:

What do you mean by feedback?

By feedback, we mean both qualitative and quantitative. Qualitative data will encourage team members to sit with the end users and look at the problem together. Review the site, and perhaps collaborate with them on an idea. For quantitative data, the team will need to dig a little deeper into the metric that you want to measure. A/B feature testing may be required, or simply week-by-week comparison, pre and post feature release. Either way, the team should be able to demonstrably point at evidence that demonstrates the effect of that feature.

Why 28 days?

When coaching teams, one of the first places we start is building in a reliable cadence of meetings that have real and specific purposes, whether it be prioritization, gathering feedback or decision making. Most of these meetings default to weekly, except one: the Retrospective. Once per month, we gather the working team to reflect on progress made. We find that, for teams operating in uncertainty, 28 days is the sweet spot between not having enough information and leaving it too long before doing anything about it.

28 days also requires that the operating work that supports agility is able to do so. For instance you may need more modular infrastructure systems that allow for frequent releases of product updates; or you may need smarter decision-making processes to take smart risks and avoid a phenomenon known as BOGSAT (“a bunch of guys sitting around talking”.)

Why “end user”?

Agile organizations are focused on consumers and customers, primarily. However, the team’s end user may not be an external customer necessarily, for example  an IT or supply chain team. It seems obvious to say, but wording is important.

How do you measure it?

This is a trickier question. In the Fortune 500s where I’ve spent my consulting career, particularly where there’s thirst for a different approach, new working practices can spread quicker than any organization development team can track it. 

For this reason, I’d propose the following: at the start of the journey, choose one diverse group of 100 or 500 people from the population. Some of them you know are involved in the agile transformation, some adjacent and some who sit deeper in the organization. Pulse them once per month with a one word Yes/No question: has a team you work on released real working product to an end user and gathered feedback in the past 28 days?

In my experience, the reason teams don’t use metrics effectively, is that they don’t know where to start. It took August four years to get to a really good place with metrics, and even now we’re still tweaking them and updating them regularly. The important thing is not the metric itself, it’s building the muscle of gathering, using and adjusting metrics. To do that, you just need to start with one.