Mirco Hering is principal director of APAC DevOps and Agile with Accenture. He supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. Mirco blogs about IT delivery at NotAFactoryAnymore.com and is author of “DevOps For The Modern Enterprise: Winning Practices to Transform Legacy IT Organizations.” Follow Mirco on Twitter @MircoHering.
OpsRamp: Why are traditional enterprises slow to embed DevOps practices across their IT organization?
MH: Most organizations say they are using DevOps somehow. But DevOps is hard to get your head around, as it has so many definitions. That’s a problem considering maturity assessments as you can’t be sure if you’re doing it right. People might say, we have a Jenkins pipeline, so hence we have DevOps. They set their goal low and then they need to declare success politically. But that gets the fundamental concept of DevOps wrong. It is about continuous improvement.
If you don't understand that mindset shift you will never get to the benefits. A common myth is that DevOps is an organizational structure exercise. If we can just get the developer and the operations people together over coffee, it will solve a lot of problems. But it’s not that simple. The emphasis on tooling has also made this more difficult, as vendors have all renamed their development and code management tools as DevOps. But you can’t buy DevOps unfortunately.
OpsRamp: What must you really nail down then, to move toward real DevOps maturity?
MH: There’s no one answer. Most problems are multifaceted. We need to understand the current situation. What is the problem, how do we know it’s a problem and then how can we improve upon it? So you run experiments and see if things change, and then you repeat the process. You might wish to understand why the website keeps glitching or why we can't release fast enough.
But you need to have the proper data in place, first of all, to see what is going on. When you do, you’ll find that maybe only one quarter of bugs are due to issues in the code, and the others are related to data integration issues and configuration issues. It requires rigor to approach problem-solving through DevOps.
OpsRamp: Has DevOps created more conflict and inertia due to confusion or conflicts over roles?
MH: What used to be narrow roles are now broader. Developers must do some testing and testers have to write test automation scripts. Some people are uncomfortable taking on a new skill because they don’t want to be seen as the one making a mistake, when before they were always a hero in their job. And those who really struggle are the traditional IT architects who used to create big blueprints and diagrams. Now, the environment is not so predictable anymore. We are deploying microservices all day long and that means you can’t prescribe the environment upfront.
Plans and designs are fluid and changing so fast. So, while we still need architects to set guidelines and principles, they need to be integrated into the development teams so it’s a two-way conversation versus a top-down dictate. The other group that’s struggling is the project managers. There’s been a notion that we don't need them in DevOps and Agile. I think that we’ve overcorrected from too much management to too little of it, however. There is a benefit of having project managers to help manage the different parties and stakeholders.
OpsRamp: In the wake of the global pandemic, will enterprises accelerate their shift towards Agile and DevOps delivery capabilities and will there be new approaches?
MH: Yes I do think these areas will accelerate. There’s an increasing need for systems to react quickly. A lot more people are hitting government systems hard for unemployment claims, for instance. And if the government adopts more DevOps, everyone else will follow. The way of working has changed as well, with people working from home. That means we will need more endpoint security and automation to help manage the work.
We don’t have the opportunity to coordinate physically, in order to get things done in IT.
“We have clients who already had high automation and DevOps orchestration before the pandemic, and they are not having problems right now doing releases with a distributed workforce”.
OpsRamp: What are some winning practices for building Agile/DevOps teams across different functions like development, QA, operations, and security?
MH: I used to be an engineer, so I understand that you have to get people interested in learning. Tactics like experiential training and dojos can be useful. With the former, you simulate behavior so you can see how the change feels. It’s kind of like a game. You can show people how things are changing or not when trying a new process. Dojos work by taking teams and putting them in a structured environment where they can learn to use the tools through hands-on practice. You’re doing the real work of the business, not some Mickey Mouse exercise on a sample application. That often makes a huge difference for the learning experience.
And people get expert help from coaches as they go. If you can operate like this for a long enough time, it will trigger change when people go back to a normal work environment. Anything less than a sprint--two weeks--doesn't really work well. It’s important for leaders to understand that you’re not going to get the same throughput from your team while they are learning in the dojo. You have to slow down to speed up. In most organizations, it is going to take 12 to 18 months to see real change once you are on the transformation journey.
Next steps:
- DevOps Metrics that Matter the Most
- How Enterprise Architects Can Help IT Operations
- Calculate your Cost Savings from OpsRamp
