DevOps for the Modern Enterprise Book Review and Q&A with Mirco Hering

Mirco Hering is a seasoned consultant on digital transformations in large organizations and has distilled his learnings and experiences in his book “DevOps for the Modern Enterprise”.

The book starts with an overview of how we got to DevOps, clearly stating common problems in IT delivery, as well as insights on why so many transformations go wrong. Hering provides pragmatic advice on long running change programs, for example how to gain momentum and support from senior management with early, high visibility, easy wins. Or the importance of baselining the transformation and collecting outcome (not output) focused evidence of progress to sustain funding over time.

Other practical aspects such as how to run a transformation governance process (spoiler: make sure all functions in the organization are represented, go light on documentation, have regular meetings, look at data and value streams rather than powerpoint presentations) or how and why bringing in vendors and system integrations partners can help large organizations achieve the transformation goals (more on that in the Q&A below).

In the book Hering shares how he has regularly looked to form “user coalitions” with other companies to pressure particular vendors to invest in making their COTS software packages amenable to modern software delivery approaches. This illustrates the kind of battle tested lateral thinking that Hering puts into overcoming natural obstacles to DevOps in large organizations.

Perhaps the only shortcoming of the book for more inexperienced readers is the lack of more concrete examples (besides the general guidance) on occasion, but this a body of work that any leader aiming at an outcome-based DevOps transformation should read.

InfoQ reached out to Hering to get some more insights from his experience with large transformations.

InfoQ: Why do you think so many organizations are still based on the Taylor model of organizing work?

Mirco Hering: I think there are a few reasons for this. For one, most managers and leaders have grown up in Taylor-based organisations and hence are in their comfort zone when operating within clear hierarchies. I have started to follow the guys behind the betacodex.org site. They provide an alternative approach based on networks and autonomous teams. I think we need more people like that who provide practical guidance on how to move away from Taylor style organisations. Another reason is that the Agile community has been very focused on the smaller groups like scrum teams and we need to take this to the organisational level now. Scaling frameworks provide some methodology guidance but not necessarily organisational change guidance.

InfoQ: Can you explain what is the transformation lifecycle and associated problems?

Hering: Transformations were a real solution at a time when you could define an “end-state” that would exist for a period of time and you had a few years to achieve this “end-state”. Think of the implementation of your first ERP or CRM system. Towards the end of that transformation you would start to focus more on reducing cost and stabilising rather than building new functionality and it worked for a while until the delta between the IT systems and the business demands became large enough to justify another transformation. By that time several leadership positions might have changed and the game starts again. Nowadays you can’t afford those long, slow transformation cycles and you also need the technical capabilities to adjust your IT systems very quickly. This means that we all started to realise there is no “end-state”. In my view the transformation towards a more Agile and DevOps based organisation is the last transformation you will ever do, because it will never finish and you will continue to evolve. Knowing this up-front is uncomfortable as there is no goal-line, but realising this enables the type of thinking that is required to be truly successful.

InfoQ: Often the people on the ground who have been through several transformations before are (understandably) skeptical of yet another one. How do you convince them that it's different this time around with DevOps and digital transformation?

Hering: This time the people are at the centre of the transformation. If this transformation is not transparent and clear to the people on the ground then it is failing. I have heard of organisations who are going through an Agile transformation and, as part of that, everyone needs to re-apply for positions and go through a traditional application process with psychometrics tests and more. This clearly conflicts with the idea of putting people at the centre of this transformation. I want people to not have to be convinced that this time will be different, I want them to feel the difference and to see that this transformation is about transparency, decentralisation and overall making work more exciting and fun. If we do this right, we don’t need to convince anyone.

InfoQ: What is your definition of modern IT? How does it feel like when compared to working in "ScrumFall" fashion?

Hering: In modern IT each person in the team is focusing a vast majority of their time on solving problems. Gone are the days of doing things just because the process says so, and repetitive tasks have been eliminated or automated. In a “ScrumFall” world the teams operate with good Agile practices but still have to perform a lot of tasks that don’t truly add value and they don’t have the flexibility to react to new information. It’s like a car that has been throttled to a lower speed than it can achieve. As we become more mature, the maximum speed increases and the throttle loses its grip on us. The initial throttle is not a bad thing, it’s natural for this to be incremental and not one big bang.

InfoQ: You clearly say automation is not a silver bullet, but in what cases specifically can it be a bad idea to automate?

Hering: This is one of my favorite questions and it comes up in many of my talks. There are three reasons not to automate a) if the process is reliable and fast you don’t have a case to automate, culture will prevail in those cases so don’t fight it - instead go after things that have real benefit because they are unreliable or slow, b) don’t automate what will shortly be replaced as you would waste your effort and c) don’t automate what you could just eradicate ( or as Drucker says “There is nothing so useless as doing efficiently that which should not be done at all.”). 

InfoQ: What are some common obstacles and processes preventing successful DevOps transformations?

Hering: I think we are still early in our transformation as an industry, the automatisms in leadership and the prevailing mental model are the biggest obstacles. That sounds very abstract. Let’s make this more real - what happens when something goes wrong, becomes harder or a disruption takes place (reshuffle in leadership, new market competitor)? What I see in many places is that cargo cult takes hold. We continue to follow some of the ceremonies and practices of the new way of working, but our culture and behavioural patterns under pressure are going back to the old ways. I have seen Agile projects under pressure spending weeks on locking down the design, or creating target velocities for each team member. It still looks somewhat like Agile from the outside but on the inside it’s the same old same.

To me this “faux-agile” or “faux-devops” is the biggest hurdle we will have to take and the root cause is that deep down our thinking and mental models have not adjusted to the new world. Truth be told it happens to me sometimes – the pressure mounts and in a moment of weakness you go back to old behaviours. What you need in those moments is someone by your side who takes you aside and tells you “Mate, you are falling back to old practices. The inconsistency will throw you back months with your team as it will confuse them. Find an answer in new ways.”  

InfoQ: In the book you talk extensively about investing in an ecosystem of vendors and system integrators (SI's) that align with the organization's vision. Can you expand on what you mean by that?

Hering: Pretty much all large organisations that I know of use in-house employees together with partners either from specific technology vendors, system integrators or contractors. Yet precious little thought leadership and experience is available in the community. To align cultures and be successful you need to consider the processes and mechanisms at the interface between these different parties. How do you structure a contract to align incentives and culture. Let me give you one simple example. A common thing to measure for a service provider that runs operations is first time resolution rate and time to resolve a problem or request ticket. The first one we want to see increase and the second one to go down as we get better. Often these are codified in contracts or SLAs. As we are moving towards more self-service capabilities, the easy tasks will be automated, which means only the more complex and difficult problems require a ticket that the team has to resolve.

But this means we will need more time to resolve those and the chance of getting it wrong with our first attempt increases. As a result our time to resolve and first time resolution rate will look worse as we increase the levels of automation. I have had many conversations with procurement teams to explain why the current contracts are not only disincentivizing good behaviours, they actively make it harder to do the right thing. Luckily, I have mostly met good procurement people who after a number of discussions have helped me shape contracts in a more aligned and meaningful way.

InfoQ: In the book you mention the importance of Dan Pink's intrinsic motivators for individuals: autonomy, mastery, purpose. But how do you align those with the organization's need for governance, efficiency and business/IT alignment?

Hering: Those are not opposites in my view. Business/IT alignment can be achieved if both sides have the same purpose and work together. Efficiency means we are doing things well and have little waste, which is an aspect of mastery. An agreed way to measure this means we are aligned on mastery and efficiency. Autonomy and governance are an interesting case to dig a bit deeper. Governance means how we make decisions and make sure those decisions are in line with the strategy and processes of the business. Autonomy should hence mean that the teams can make decisions, that they understand the principles on which to base the decisions and how the results will be evaluated. Governance is the evaluation of those decisions and to provide feedback that the teams can learn from. Of course there will be cases where corrective actions are required. I believe they will become less and less frequent. In a transparent organisation the peer pressure and intense information flow will have a somewhat self-governing effect and until then we try to find the minimum viable governance.

InfoQ: In the book, you frequently recommend running cross-teams workshops to discuss how to evolve capabilities or define roadmaps. Do you see that as a defining trait of a learning organization - making room for evolution beyond the routine of on going projects?

Hering: Absolutely. A learning organisation has 3 defining traits at its core: 

1. It provides capacity to run experiments for improvements (and any implementation of a DevOps practice, for example, is ultimately an experiment)
2. It understands how to measure progress and evaluate success (this is where most continuous improvement efforts fail, they don’t have clear measures of success)
3. It allows people to learn from failure in a blame-free environment. I have learned from my many client engagements that it is so much easier to blame someone else or redirect responsibility when they are not in the room. If you run cross-team workshops and facilitate them well, you can avoid those behaviours and do real analysis and problem solving with no finger-pointing. It is pretty rare to see anti-social behaviour in those workshops and if you do, then you have found the first problem to address…

InfoQ: Vendors and especially SI's are hardly ever part of the conversations around DevOps. Instead there's a strong focus on building in house engineering capabilities. When and why does that option fall short?

Hering: I don’t think it is so much a falling short, I think the right strategy is to identify the right balance. I don’t believe many organisations will do everything in house for good reasons. You want to have access to people who have done similar things in the past. “Why invent every wheel yourself again?” SIs have career models that attract a certain kind of person, people with deep technology skills but feel the need to do something different every so often. To have access to those people you either have to work with an SI or with contractors and my view on that is clear. I find an over reliance on contractors dangerous as too many of them work on the basis of client reliance and are not interested in making themselves redundant. I aim to work with a client for a maximum of 2 years to help them upskill, increase their maturity and leave them in a good place, that’s what a good partner does.

There are two areas where ongoing involvement can be of immense value, in the space that you don’t want to continue to invest (the legacy) and the space where you want to continue to innovate. In the innovation space it can be helpful to have a partner that has access to many different environments and can bring that information to your organisation. So yes, build your inhouse capabilities and yes, establish partnerships. I like clients with strong in-house capabilities as it is a lot easier to have meaningful conversations with such organisations who speak the same “language” than it is to talk to an organisation with insufficient engineering capabilities. 

InfoQ: Your book is mostly based on results you've experienced consulting with clients, right? What are some common reasons they ask for help and how do you go about grasping the root causes when they present you with the symptoms?

Hering: That is correct. I have done some work internally with our own teams, but I spend a lot of time directly with clients. A friend of mine recently shared with me his views of why a service provider like Accenture is still very relevant in a world where more and more organisations are in-sourcing IT work and knowledge. Let me just share a few of those: I like my work because I get to work in many environments and with many technologies. This breadth of experience is difficult to attain if you only work in one organisation. If you combine an experienced consultant that has broad experience with people from the client organisation who have the internal context and deep functional and technical knowledge of their world, you can be significantly more successful than by reinventing the wheel in your own organisation because it is your first transformation. Of course there are other ways like hiring people from the outside, but in my experience having a “neutral” person in the consultant can be very advantageous for the change journey.  

Other benefits can be the deeper relationship that a partner might have with technology vendors, access to a flexible workforce to buffer high/low demand, access to niche skills to name just a few. I think my role as consultant has become even more meaningful in a market where there is so much confusion and ideology that can distract from getting results. Clients who embark on a transformation want our help to avoid common mistakes and our insights into their context and finding out what the problems are. Just recently I worked with a client that is facing delivery challenges. They have brilliant technical people but after just a couple of weeks of working with them and being at the coalface I saw patterns that I had seen in other places and was able to help them gain a new perspective. So to answer your question, working with the clients on something real and leveraging the experience from many other places is how I get to the root cause. It is my strong view that you cannot do this with a questionnaire or maturity model – those can help to give you an idea of the landscape, but only going where real work takes place (or to use a popular Japanese term “Gemba”) can give you deep insights.  

About the Interviewee

Mirco Hering leads Accenture’s DevOps & Agile practice in Asia-Pacific, with focus on Agile, DevOps and Continuous Delivery to establish lean IT organisations. He has over 10 years experience in accelerating software delivery through innovative approaches. In the last few years Mirco has focused on scaling these approaches to large complex environments. Mirco is a regular speaker at conferences and shares his insights on his blog.