I have been speaking over the last couple of years about the nature of DevOps and Agile transformations. It is, in my view, not possible to manage them with a simple As-Is To-Be approach as your knowledge of your As-Is situation is usually incomplete and the possible To-Be state keeps evolving.

You will need to be flexible in your approach and use agile concepts. For successful agility, you need to know what your success measures are. This allows you to see whether your latest release has made progress or not (something way too many Agile efforts forget). What could these success measures look like for your transformation?

<<< Start >>>

<<< End >>>

There is not one metric, but I feel we can come up with a pretty good balanced scorecard. There are four high-level areas we are trying to improve: Business, Delivery, Operations and Architecture. Let’s double click on each:

  • Business: We are trying to build better solutions for our business. And, we know we can only do this through experimentation with new features and better insights. So, what measures can we use to show that we are getting better at it?
  • Delivery: We want to streamline our delivery and get faster. To do that, we will automate and simplify the process wherever possible.
  • Operations: The idea has moved from control to react, as operations deals with an increasingly complex architecture. So, we should measure our ability to react quickly and effectively.
  • Architecture: Many businesses are struggling with highly monolithic architectures or legacy platforms. Large-scale replacements are expensive, so evolution is preferred. We need measures to show our progress in that evolution.

With that in mind, here is a sample scorecard design:

I think with these four areas, you can drive and govern a transformation successfully. The actual metrics used will a) depend on the company you are working in and b) evolve over time as you find specific problems to solve. But having an eye on all four areas will make sure you are not forgetting anything important and you’ll notice when you overoptimize in one area and something else drops.

Next time I get the chance, I will use a scorecard like this, of course implemented in a dashboarding tool so that it’s real-time.

Mirco Hering

Global DevOps Practice Lead – IT Transformation & Delivery

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog