BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News DevOps Needs Continuous Improvement to Succeed

DevOps Needs Continuous Improvement to Succeed

This item in japanese

Bookmarks

Continuous improvement is not a new thing and is often misunderstood. To be successful, we can take guidance from agile principles and apply them to the DevOps world, argued Mirco Hering, managing director at Accenture. At Agile Portugal 2019 he spoke about DevOps leadership in the age of agile.

Hering believes we are way beyond the point where DevOps and the associated practices like Continuous Delivery are not well enough understood, yet we don’t see many organisations reach a mature state of DevOps. He mentioned two themes that are preventing organisations from making faster progress.

The first one is a tendency to declare success too early; adopting DevOps practices is hard work and a lot of the benefits come with the last 20% rather than the first 80%. After all, a semi-automated process is not that much better than a manual process, argued Hering.

The second theme is around organisations adopting the old approach of transformation to DevOps, which means they either try to reorganise themselves out of their problems, or do the equivalent of an As-is To-Be analysis to define their transformation plan for DevOps. Both approaches are destined to fail, said Hering. Rather than charting out the whole DevOps journey, we need to accept that only rigorous continuous improvement will allow you to make significant progress; things will change all the time and you need to be able to react to it in an agile fashion.

Hering stated that organisations tend to lack two things in order for continuous improvement to really work: the discipline to follow the more rigorous process, and the data to set baselines and measure improvements.

Hering stated that continuous improvement is often misunderstood. Many organisations create a list of things to improve and track, whether or not they have implemented them, and call that continuous improvement. "This is just not good enough", he said, "it often leads to increasingly long checklists for people to follow because adding a step in that list is an easy way to feel like you improved something. Does this actually improve anything? Who knows…"

We are getting better though, said Hering, as there’s a lot more talk about gathering and using data from our DevOps tools now. Open source solutions like hygeieia and efforts by established vendors indicate an increased investment in this space. Hering encouraged companies to take control of their data and find ways to use it during their transformation.

Hering spoke about applying ideas from the agile world to DevOps at Agile Portugal 2019. In his talk, he gave some examples:

When I first worked with Agile, one thing that resonated strongly with me was the principle-based approach. If you understand the principles, then methods will follow. I prefer this very much over the "war of frameworks" that seems have broken out in some parts of the Agile world.

Systems thinking was such an eye-opener for me when I got introduced to it in my first agile trainings. Here is where this applies to DevOps I feel: if we allow every team to create their own tooling and approaches to DevOps then we have optimised for those teams to the detriment of the overall organisation. It is very difficult to maintain an architecture when every team can do what they want. So what constraints and alignment do we require to optimise the whole system instead of just improving each team.

Continuous improvement is not a new thing; there are practices such as the Deming cycle dating back to the previous century. Hering shared how to use the Deming cycle as a scientific method for continuous improvement:

We have an idea about what can improve the situation. We are designing an experiment to see whether we are right and agree what data we need to validate that. Then we implement our idea and compare the results afterwards. Whether it worked or not, in either case we have learned something that influences the next experiment in our continuous improvement journey. For example, that increasing code coverage is not actually improving our quality any longer at some stage.

Rate this Article

Adoption
Style

BT