agile journeys

...rants by Asheesh Mehdiratta on Coaching, Transformation and Change

Tag: metrics

Why MTTR is my favourite metric?

December 21, 2017 /

metrics devopsAs you walk the DevOps Transformation journey, you would build out success stories, build metrics and start to energise teams towards continuing improvements. But to quantify the end user experience, I always look towards the MTTR (Mean Time To Recover) metric.

MTTR is defined as – Average time required to repair a failed component or device. ITIL definitions can be more expressive.

Why MTTR is so useful and is my favourite metric?

Here are few of my reasons –

  1. MTTR captures the End user EXPERIENCE,  by capturing when a service goes down and when it is restored.
  2. It shows the SPEED at which your team/organisation works!! Including how quickly the team –
    1. Acknowledges the problem
    2. Solves the problem
    3. Communicates the Resolution to the end user.
  3. MTTR encapsulates the internal dynamics of the teams /organisation.
  4. It is a simple metric and easy to understand metric, without any ambiguity.
  5. It can be measured in any unit (hours/days), which everyone can understand, including the Dev and ops.
  6. MTTR can be captured easily, automated and put across in the dashboard showing trends.
  7. It is applicable across all systems, of varying complexity and size.
  8. MTTR is technology agnostic, and can be understood by everyone – management, executives, support, operate and developers.
Conclusion

You do not want to measure anything, unless it helps the teams/stakeholders, but sometimes you may get carried away to the other extreme of measuring everything also. But MTTR is a simple, easy to understand, easy to capture metric, which serves the purpose of showing the inefficiencies and reminding the teams of the end user experience every time!

So what has been your favourite metric? feel free to share your feedback in the comments below.

If you like what you read here, then do share this article, and subscribe to my future articles. 

ALL Metrics are Useless except what you need !

November 4, 2017 /

metrics

For a large number of enterprise shenanigans, Metric creation, collection and measurement can sometimes become a way of life ! They do not really care what the metric destroys, the impact on the human behavior and how these Metrics are simply — USELESS ! The typical story line has been made famous by the myth around –

WHAT YOU MEASURE IS WHAT YOU GET !

(chasing the WYSWIG rainbow made popular from Wintel era)

and then this is supported by, You can Measure ANYTHING, which simply simmers the already hot embers.

But we need to watch for Albert Einstein’s quote – “Not everything that counts can be counted. And not everything that can be counted counts”

But the real question to ask is –

Do you really need to measure <fill in your favourite metric here>?

Have you ever wondered how the intelligent folks will react when they hear that they are being measured on this metric ?

What will you do as a sane individual ?

Will you ignore this metric if you know someone is tracking and watching this metric? especially if you are caught in the day job cycle, and your promotion depends upon improving this metric?

The answers can range from subservient YES to timid agreement mostly.

But what we are really looking for when thinking of a metric is changing behavior, so that it provides feedback to ignite the FIRE within the individual, within our organization.

So if you are thinking about introducing a new metric, think Twice !! Even if you still insist that you really need this metric, then don’t make THE Metric your GOD, which needs to be fed, but instead make it a Servant for yourself, for your team ! and use the metric as a feedback to improve your condition, your team’s current state and move towards your target state.

Do share your stories on  – What has been your most scary metric?  Which metric you hated ? Which metric made you do the opposite ?

Subscribe to my blog , and feel free to share your feedback here.

© 2024 agile journeys

Theme by Anders Norén — Up ↑