Time to Value – a perfect metric for devops

5 Replies

I recently heard Jesse Robbins (co-founder of opscode) talk about changing culture & devops.  During this awesome talk, he said that organisations that get devops right see a massive improvement in the metric “time to value” – I love this metric.  Before I elaborate more on this, here’s some context.

Opscode, in addition to making Chef, help organisations implement full infrastructure automation.  Drawing from this experience he says organisations generally go through these steps:

  1. Discovery and visibility
  2. Automate common tasks (scripts, OS, updates etc)
  3. Implement automated configuration management
  4. Implement automated application management
  5. Continuous Deployment
  6. Full Infrastructure Automation

ScreenShot139So what is “time to value”?

The time it takes for the business to realise value from a piece of work e.g. a piece of development work.

On first take this metrics feels a little thin – doesn’t continuous delivery just address this? …but on reflection there’s much more to it.

Why is “time to value” an awesome metric?

  • With this metric, teams that focus on “lean” methods win (great way to encourage shipping early)
  • It scales – time to value of an individual feature vs time to value from a larger deployment of new hardware
  • The metric measures and accounts for business decision making speed as well as technical implementation e.g. do business decisions go through too many committees?
  • This metric unites dev and ops working towards shipping things

Anyone who is managing devops should read Jesse’s slides on hacking the culture to improve their time to value.

  • peterhedenskog

    I’m also a big fan of “time to value”, however seems like I always have trouble getting the business understanding their part of the deal: Say that we have a lean way of implementing changes and putting it to production, a process measured in hours or a day. The business part however can take weeks/months to get their decision. But I have NEVER heard a complaint that the business is too slow :)

    I have only seen “time to value” been calculated from when the business decision already have been taken, meaning the time it takes to get the things prioritized for the developers, implemented and put into production.

    • richsteer

      thanks for the comment. Yes I agree the business never thinks its slow! It’d be interesting (although hard) to measure time from the original idea inception. In the absence of that, you’re right measuring the devops part is the next best thing.

  • http://www.opscode.com/ Jesse Robbins

    (hey… my name is Jesse, not Jesse ;-)

    Glad you got so much out of this. One comment: When you are thinking about the three pillars to achive Time to Value, it is helpful to put it in context with the many subareas that help an organization to move faster.

    Here’s the slide where I break some of it out…

    • richsteer

      sorry Jesse – all corrected now! thanks for the follow up comment, that is a great slide to help communicate change :-)

  • Pingback: DevOps – How do you measure team success? | Dev Ops Guys