DevOps isn't a tool to be applied selectively

Several times lately I've come across the idea that DevOps is a localised technique which can be used on one team or application, and not another. This isn't true. DevOps is a cultural transformation,a journey not a state or a tool. The primary goal of that transformation is to increase collaboration towards a common goal, to break down silos. A bi-modal model achieves the opposite.

I never thought I'd end up disagreeing with Michael Cote but I disagree with this:

    You can't DevOps everything, kids. Off the shelf kit especially... you don't always need to do the DevOps. In fact, in many cases, it's likely a waste of effort... unless you're writing and running your own custom software, there's little benefit to transmogrifying yourself to DevOps... focusing on the right strategic projects is key. Don't waste your precious DevOps resources on the back-office and commodity IT

That article perpetuates the Bi-Modal Fallacy, that it is OK to maintain two cultures, two Ways Of Working, in one IT shop.

In 2016, the Pink Think Tank (I was its Producer at that time), concluded in our white paper (pdf) that:

    the goal of this [bi-modal] model is to create a duplicate IT function with different values, practices and priorities from the rest of the organization with a goal of creating fast track assembly lines for key IT services in order to address a core area of business dissatisfaction related to the speed of supply.
    Unfortunately the side effect of this model creates a high degree of disconnect within the organization; trading speed in one area for increased disunity and increased dysfunction by creating further entrenched cultural silos.
    Rather than focus on an oversimplified two mode model, it is critical to acknowledge that the organization by their nature will have services which run at different speeds (Multi-Speed). The key is that organizations need to adjust their processes rather than create duplicate structures in order to balance the need for both speed and quality.

One of the Think Tank members rudely described it as the "bi-polar model" :-) There is plenty of criticism of it. Forrester described it as "fatally flawed". The DevOps Handbook rejects it on page 56:

    when we improve [legacy] systems we should not only strive to reduce their complexity and improve their reliability and stability, we should also make them faster, safer and easier to change

Bi-Modal leads to two cultures, two tribes, the exact kind of division which DevOps is trying to overcome. (It also leads to what I call "Chernobyling", where management pretend legacy systems are covered in a huge concrete dome).

Simon Wardley slammed it using his town planning analogy:

    You’ll create a them vs us culture. None of the novel concepts will ever be industrialised because the Pioneers won’t develop them enough and the Town Planners will refuse to accept them for being underdeveloped. Both groups feel they are the most important and both ridicules the other.

See also
Jez Humble.

Some people get it. Here is another voice (my old mate Charlie Araujo) saying how DevOps must be adopted holistically, not app by app.

    At its core, DevOps is a cultural transformation — a new way of working and collaborating — that brings the organization together to deliver better services more efficiently, rapidly, and reliably. While adopting DevOps principles in narrow bands within an organization made sense for companies experimenting with this new concept, the entire organization must ultimately apply such principles holistically throughout the enterprise to be both effective and transformative...
    Organizations should not view DevOps as a project or even a methodology, but instead as an overarching philosophy that governs how the entirety of the IT organization operates.

Charles goes on to nail the source of the fallacy:

    Organizations should not confuse DevOps with its closely-related cousin, the Continuous Delivery (CD) movement. CD is essentially a structured process by which developers continually integrate code throughout the development lifecycle and, using high degrees of automation, rapidly test and deploy that code into production. CD is a powerful approach ... but it is not necessarily a good fit for every application within an enterprise... Organizations should, therefore, apply CD principles on an application-specific basis.
    This is not true of DevOps. Instead, organizations should adopt it holistically, embracing it as the new way work gets done within IT, and by extension, throughout the entire enterprise

DevOps is a transformation to a New Way Of Working, CALMS: Culture Automation Lean Measurement Sharing. Just because you don't do unicorn-grade automation in a particular value stream doesn't mean you aren't doing DevOps.

You don't change culture team by team or app by app. You don't get to pick and choose where you DevOps. You can do it for a while - operating bi-modally - in order to experiment, to allow new ways of working to incubate, but it is essential to converge quickly. DevOps is not a piecemeal tool, it is an organisational transformation.

Syndicate content