For any Executive thinking of introducing Metrics, they need to understand that there are three level of Maturity:

• Step 1: Map Investment to Metrics.
• Step 2: Use Metrics to demonstrate Success.
• Step 3: Use Metrics to assist Decision Making.

Your metrics will mature with your (understanding of) your Product. Do not expect to build the perfect Metrics system in one go. Rather your Metrics system will evolve with your product. Consider building a road:

1. You lay the paving stones where the grass is bare and muddy.
2. Someone watches the path for a few days to see if is used enough to justify an upgrade. If it is, we build a one lane road.
3. Next we lay a rubber counting strip across the road to electronically count the cars using the road.
4. By the time we have a seven lane highway like those in Los Angeles, we have real time tracking of cars and an advanced flow management system that controls the number of cars allowed onto the highway.

In other words, start small and evolve your metric system gradually.

Level 1: Map Investment to Metrics.

Before your product owners get to invest, make sure they know what they are trying to improve. Get them to specify which business value metric they are hoping to move. Use Cynefin to help them understand whether their investment should a definite improvement on a metric or whether they should be testing a hypothesis.

Get them to map their Stories (Or Epics) to a business value metric.

• In order to improve conversion on the pay channel
• As a customer
• I want the pages to load faster
• So that I do not lose focus and attention to the task at hand

( Pay channel conversion is the value metric. )

Once your organisation has simply mapped their work to metrics, you will have a strategic view on where investment is taking place. To illustrate this, lets start by looking at you portfolio without a mapping to metrics.

As an Executive, there is little you can do but ask about the details of each Widget and DoDah.

Now lets map each Story/Epic to a Metric…

Doesn’t look like much but lets consider some of the analyses we can do:

As an executive, you can create an aggregate view of metrics that you cannot create by looking at functionality.

Now you can see that you do not know where most of your investment is going. You can also see whether the other metrics are the right ones to invest in depends on the state of your metrics.

The key is that you do not know which metric you should be investing in until you know the health of all of the metrics in your portfolio. When starting out, you may not have the perfect comprehensive view in which case you’ll have to “lay the paving stones where the grass is bare”.

The next two blog posts will focus on level 2 and level 3, “Use Metrics to demonstrate Success” and “Use Metrics to assist Decision Making”

Photo Credits:

• Muddy Path – https://pixabay.com/en/users/Free-Photos-242387/
• Stone Path – https://pixabay.com/en/users/TheAndrasBarta-2004841/

Over Christmas I introduced the Hedgehog strategy for Agile Transformations. Unlike the fox who is very clever, the Hedgehog does one thing well. The Hedgehog strategy I suggested was to “Reduce Lead Time”. This is a great strategy for an IT Director or CIO. It is not a very good strategy (on its own) for an organisation. In particular it is not a good strategy for the business or product leadership. An organisation needs two Hedgehogs, one for delivery, and one for product.

The Product Hedgehog strategy is very simple…

Insist that every investment delivers value by increasing a business value metric.

Why is this so important? The answer is because of what happens when you do not. When you do not insist on improving a metric, the team will do the easiest thing which is to agree a list of functionality to deliver instead. This leads to all sorts of naughtiness. Some common symptoms of failing to focus on value are below:

1. The team focus on delivering functionality rather than something of value to the customer.
2. Teams build what they can build easily rather than build what the customer needs or wants.
3. An executive with no detailed knowledge of the investment will decide on the functionality of a product after being presented the “options” by the team.
4. No consideration of the customer’s needs. Although everyone will talk about customers, they will have no empathy or understanding of the customer and their needs.
5. A rapid turnover of User Experience Researchers. It is obvious when you do not use a designer, but UX Researchers are easy to dismiss. UX Researchers are highly sought after and will move if you do not value them and use them.
6. Executive steering committees are spent discussing functionality rather than metrics and value (mainly because the team have no metrics and can demonstrate no value… other than in the “Business Case”).
7. User Testing always results in success as teams value “being right” over learning about the customer.
8. No interest in establishing a baseline for the business value metrics.
9. Large Waterfall Style releases of “value” as teams see no value in releasing small increments to learn from customers.
10. Success of the product is based on the opinion of the Executive Steering Committee rather than based on facts and data.
11. No investment ever fails. No one is ever sacked for the failure of the investment… which is the whole point of not using metrics in a risk averse culture.

Do you recognize any of these symptoms on your “Agile” project? Or perhaps you have other examples that I you could leave in the comments.

So do your organisation a favour and unleash the Hedgehogs of Success:

1. Reduce Lead Time.
2. Deliver Value (as evidenced by Business Value Metrics).