How to know if your organization implemented DevOps right.

Many IT leaders sometimes brag about the DevOps capability they implemented, but a close look at it shows it’s not consistent with what I call Authentic DevOps.

Today, DevOps is a buzzword that’s lavishly used to address conflicting concerns, expectations, and visions. While a minority sees it as a software deployment approach that ingeniously mobilizes human factor, Agile and Lean practices, automation toolchains to speed up business priorities delivery and make it profitable, the vast majority narrows it to an automation toolchain and pretends it makes the business competitive.

You can call whatever you want “DevOps”, the fact is, if it doesn’t comply with certain principles and requirements, it’s not DevOps. Period.

The DevOps Assessment Maturity Model (DA2M) which is part of the DevOps Now™ framework I developed two years ago, has been helping many with their DevOps implementation. Understanding it will tell you a lot about how to properly implement DevOps.

The secret of high ROI DevOps implementations combines four strongly coupled requirements: Automation Toolchain, Human Ingenuity, Agile Practices Adoption, and Value Stream Optimization.

As the picture shows, the DA2M is structured around four strongly coupled requirements— Automation Toolchain, Human Ingenuity, Agile Practices Adoption, Value Stream Optimization — they all together, not one, two, or three, but all together, determine DevOps’ business benefits.

Each requirement is characterized by a set of practices which enable a specific value driver. Example in the model, the requirement “Automation Toolchain” is a set of architecture design and implementation practices that enable the “CI / CD Infrastructure” value driver. The amount of DevOps’ benefit increases as more requirements are met. Example in the model, the requirement “Automation Toolchain” alone delivers “Chaos” if the requirement “Human Ingenuity” is additionally met, “Speed” is the benefit you get as more releases are delivered, faster, but are unfortunately irrelevant for the business, and so on.

Digital Transformation Consultation

The DA2M is a snapshot of frequent DevOps configurations identified by the benefits they deliver and pluses — the assets they bring — and minuses — the assets they lack.

Chaos stresses the CI/CD infrastructure as the only value driver that matters. It assumes that accelerated software delivery enabled by toolchains involving solutions like Git, Jenkins, Docker, Kubernetes, is all businesses need to compete. The problem with that vision is, it underestimates the need to build on resourceful staff as a means to deal with the challenges of the fast-paced and changing environments, particularly the problems inherent to the emerging technologies — experts shortage, steep learning curves, and paradigm changes. In addition, as it limits IT’s role to providing applications and tools, it either ignores or disbelieves in agile and lean methodologies as drivers of competitiveness and revenue. This perspective supports 90% of today’s DevOps capabilities.

How Learning Organization, Agile, and Lean methodologies make DevOps a powerful business enabler

In the Speed configuration, the company builds on the CI/CD infrastructure and on Resourceful Staff to deliver priority software. The belief is, automation toolchains’ computing power combined with a best-effort mindset involving resourceful staff makes the business competitive. The problem is, it doesn’t provide the expected business benefits because it underestimates agile development methodologies’ ability to accelerate interactions across the organization’s value stream and therefore to reduce time-to-market and time-to-revenue. Moreover, by ignoring the influence on the organization’s value stream of approaches like Lean Production, it clears IT of its responsibility to contribute to value. This erroneous vision is widely spread in the IT community.

The Time-to-Market option successfully combines CI/CD infrastructure, Resourceful Staff, agile mindset and philosophy to deliver highly profitable software. That approach rightly believes that speedy delivery enabled by powerful toolchain and resourceful staff immersed in agile business environment is likely to foster not only shorter time-to-revenue but also innovation to make the business competitive.

The shorter Time-to-Revenue approach is what I call authentic DevOps. It sees the ability to continuously deliver high priority and added-value software as the must-have competitive advantage. It rightly claims that prioritization, collaboration, agreement, consensus, decision-making, and innovation are all part of the software delivery process. Yet, they’re human concerns and cannot be addressed by toolchains involving Git, Jenkins, Chef, Docker, Kubernetes. They require human ingenuity, hence the central role of Agile and Lean production methodologies.

In addition to providing accelerating software development and deployment techniques, Agile methodologies like Scrum, offer powerful value stream optimization mechanisms. Scrum tools like User Stories, Product Backlog, Sprint Backlog, Sprint Review, Daily Scrum have no other goal than foster the human concerns mentioned above in an effort to accelerate time-to-market and time-to-revenue.

Implementing DevOps right is about equipping the organization with four value drivers: Automation Toolchain, Human Ingenuity, Agile Practices, and Optimized Value Streams. Not only the automation toolchain!

The key thing to keep in mind is, we do IT to help the business generate value including market share gains, revenue growth, brand value increase, and more like it. The fact of the matter is, most DevOps capabilities aren’t implemented to fulfil that mission; they’re designed to speed up applications assuming it yields business benefits. It does not!

If you’re a business and your DevOps capability doesn’t comply with the Time-to-Revenue level of the DA2M model, ask yourself this:

“Why did we invest in DevOps? Was it to make IT happy or to boost the business?”

If you’re a consultant involved in a project, ask yourself this:

“To what extent does the DevOps capability we’re implementing comply with the Time-to-Revenue level of the DA2M model?”


Article by channel:

Read more articles tagged: DevOps, Featured