Cargo Cult DevOps
It began with this blog post, which I wrote initially in December 2017 for a paid freelance blogging contract. Since then both my message has softened, and the blog editors revoked the link to the original post so I cannot link to it now. I post this follow-up post here as written, and hope you take it as viewpoint in a moment of time, with some strands of helpfulness woven therein.
While “imitation is the sincerest form of flattery”, that’s all it is: Imitation.
It might be flattery and the behaviours might be similar or almost identical, but it’s not context relevant, and thus neither truly helpful.
I have for years now been a fan of this reality-inducing blog post by James Shore: http://www.jamesshore.com/Blog/Cargo-Cult-Agile.html. It is a fascinating read, and highly recommended. It is not only helpful in understanding cargo cults in general, but also cargo cult “Agile”.
And so too is this post by Agile Manifesto signatory Dave Thomas about the proposal to do away with the “Agile industry”: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html. I also saw him deliver this talk at a conference keynote 3 years ago and found it to be a very convincing argument.
Both articles talk about the cult-like and cargo-cult-like following and imitation of Agile. It has been my (and several others’) opinion for a while now, that we are doing the same thing to DevOps.
You may have seen me allude to cargo cult DevOps in my articles before, but this time I wanted to write about it explicitly. I asked this question on Twitter: https://twitter.com/TheresaNeate/status/995257873289494528.
This has led to me compiling the below.
To me, cargo cult DevOps looks like this:
Proper Noun DevOps.
Similar to Dave Thomas’ talk regarding proper-noun Agile, in some ways DevOps has become an industry that has lost sight of the original intentions when Patrick Debois formed DevOpsDays (the first use of the word) in 2009 — i.e. to have “Agile infrastructure” with development and operations working better together.
Consultants selling “DevOps transformations”.
Beware consultants who are billing hours to “make you DevOps”. There is no end-state state called DevOps, there is only a way of working which continues, is never perfect and by its very definition requires continuous improvement.
Over-complexity.
Beware complex frameworks and roadmaps. If you “get” what DevOps is set out to do, it becomes simpler and you will be able to eat this elephant one bite at a time. Understanding generates greater simplicity.
DevOps titles and teams.
As already mentioned in this article: https://medium.com/@theresaneate/when-you-have-a-separate-devops-team-you-are-not-doing-devops-3417e9c8464
DevOps is not a fancy, modern term for Operations. It’s a way of working between all Development and Operations roles (which includes QA and Security and other members of the team) requiring Culture, Automation, Measurement and Sharing (see more below regarding Tools).
The sardonic tone of this tweet by Roy Rapoport echoes the misuse and misunderstanding of DevOps by making it just “modern Ops” and how the industry can get it wrong: https://twitter.com/royrapoport/status/996013869230272512
DevOps silos.
By creating a DevOps team, not only have you missed the point of collaboration (DevOps is how we work, not where), but also have you just renamed your silo. Again, something I have already written about.
When DevOps is not explicitly about helping others do better work.
As my friend Colin Panisset said so eloquently in this tweet: “Any situation where “who”, “what”, “where” or “how” is used instead of “why”, or if the “why” isn’t about improving the flow of value and the lives of the people involved?”
Thinking it’s just about Tools/Automation.
CAMS (an acronym created by John Willis, and mentioned earlier) is short for Culture, Automation, Measurement and Sharing. If you are handing teams shiny new “DevOps tools” and not changing anything else, you have it wrong. Automating everything but not applying feedback/measurement to your automation, not removing obstacles to working efficiently, not sharing your lessons with others, etc. — is imitation and incomplete Dev-and-Ops-collaboration.
Getting careless “in the name of DevOps”.
I remember the days we were afraid Agile was just “a bunch of cowboys” — turns out, some actually were! Some were cutting corners and being shoddy programmers in the name of Agile, and so marred its name. Same goes for DevOps — if you are firing wholesale certain roles, no longer applying scrupulous & meticulous feedback to your release process, etc. because you are going “lean and applying DevOps”, then you are imitating and not understanding. (One such behaviour is by getting rid of testers, which I wrote about here: http://rea.tech/do-we-need-qas-testers/.)
The possible antidote to cargo cult DevOps
First, educate yourself with the materials by the original authors of Agile & Devops and their predecessors — including Patrick Debois, Taiichi Ohno, Eli Goldratt, John Willis, Damon Edwards, Gene Kim, W. Edwards Deming, John Allspaw, and their peers.
Secondly, ask Why? Define your problem before working out how to solve it, who is involved, what it will cost, etc.
To quote John Allspaw:
“Reminder that it takes just as much effort (time, money, staff, etc.) to build the wrong thing as it does the right thing.
“Problem discovery is under appreciated as a practice in software engineering, especially when compared to problem solving.”
Thirdly, DevOps is by definition Agile — so, as with Agile, keep any implementations simple & iterative. Learn and adjust continuously from every step of your implementation. Leave the Big Bang to evolution.
Lastly, learn and apply emotional intelligence and social science to those with whom you interact. No matter how many tools and processes and systems you deal with, you are first and foremost working with people.
