A Framework for continuous DevOps improvement

Automation Logic’s Partner and Co-Founder Kris Saxton Recently spoke at Computing’s DevOps Live Event on a Framework for continuous DevOps Improvement, highlighting the necessity of measuring results in order to ensure your DevOps Project is headed in the right direction and how to get started.

If you’ve ever found yourself pondering on these questions…

Where do I start?

What does good look like?

How will I know I’m getting there?

How will I know if I’m not?

…Then keep reading, this post will highlight the key points and aim to answer any questions raised on the day.

So why do we measure? We measure because not only are we less likely to hit the mark ‘shooting in the dark’, but we have no way of correlating our activity with our outcomes because we aren’t getting any feedback often –  for months on some of the longer term cultural capabilities like trust and autonomy. Without regular feedback through data, it is impossible to improve.

We look to Robert V. Hogg, President-Elect of the American Statistical Association, for clarification:

“In God We Trust, but others must have good information and data which they can analyze correctly by constructing appropriate models.”

So, where to start?

Start by measuring these things:

By asking questions like these:

Get results like this:

Analyse these scores, create a sprint plan, and then you have a Framework.

Scores, Analysis, Roadmap. Repeat.

Tying it all together, you have Empirical Process Control.

Now for the FAQ’s

Let’s start with the important stuff, for those who attended DevOps Live, what’s your favourite dinosaur and why?

‘Any of the Sauropods’. (To recap, they remind him of our engineers ‘Endless patience and incredibly thick skinned!’)

Does measuring slow you down?

Yes; but so does stopping to look at a map, I assume I don’t need to expand on that metaphor? If you think of measuring purely as an activity, it will always be seen as an overhead, because it takes time and doesn’t directly relate to the work at hand. However, if you want to measure progress towards an outcome or a goal, then you will generally progress faster with periodic measurements because you can course-correct.

Think of it as the difference between running in any direction vs. running perhaps slightly more slowly, but always towards the goal. In the long run, it’s going to save you both money and time.

How do you measure trust and cultural aspects in general?

Maybe you can’t measure culture directly, but you can measure it indirectly. Start by looking at things you would only find in a high trust culture. Things such as high levels of autonomy, low levels of bureaucracy and process. Perhaps one method that is slightly harder to measure, but worth noting, is observing attitudes to failure, people will be less scared to fail in a high trust environment or a genuine ‘no blame’ culture. You’ll see people focussed on solving the problem or achieving the outcome rather than expending energy assigning and avoiding blame.

What are the most common mistakes you see?

Adopting the tools and processes without investing in changing the underlying mindset and habits. That is by far the most common. This is mostly in large companies, I think because it’s much harder to affect cultural change in a large organisation, so much so that people often avoid it and focus on what they’re more comfortable with (e.g tooling).

How do you manage too few staff?

The most common response to any resource shortage is centralisation and rationing.  This can go against a core principle underpinning DevOps where every team has everything they need (including DevOps skills) to deliver value within said team. Despite this, in most cases, scarcity forces what is often called a ‘liaison model’ with a central DevOps team managed like a shared service.

However, rationing is a tactical response.  An alternative for the more long-sighted is to pair tactics with a more strategic approach which involves growing your own talent. We did this ourselves with our AL DevOps Academy because we understand first hand how scarce the talent is. So either an Academy model and/or a focus on upskilling your existing talent by partnering with companies like ours can ensure that you are always building your internal capability.

How do you change the culture from an IT concern to a business concern?

The most enduring way to achieve that shift is to change how you organise yourselves, and that is fundamentally what DevOps is, an organisational model designed to connect a team with a business goal, usually through as a product or service. Start on a small scale (with one team) and grow it out, that’s one of the great things about DevOps, it scales very easily.

How do you take the next step to tackle the larger aspects of legacy infrastructure?

The first step in scaling anything is to systematise it and to do that, you need a framework. (see above) The only thing I would add to that is that even with a framework, you can only be as effective as your most senior stakeholder. In order to move beyond experimentation and effect the necessary organisational changes that are required to scale, generally requires senior management support. That’s senior management from the whole business, not just from those focussed on IT, it has to be the whole leadership team getting involved.  

If you’re still not sure you’re on the right track with your DevOps Projects or want to see an example of a DevOps Assessment with results and a tailor-made prioritised roadmap then get in touch with us. We offer a complimentary DevOps Assessment for those businesses we think we can be of assistance to. Contact us on info@www.automationlogic.com.

Visit our DevOps service today!