If you are familiar with, or buy into the idea of the Hype Cycle, you are familiar with the Trough of Disillusionment. When it comes to adoption of pretty much anything, there seems to be a point, just after the peak of enthusiasm, where those in the know are disappointed with the practicality and adoption rate of their thing or cause. Now that DevOps is several years old, and, in the last year enthusiasm has been at an all time high, is DevOps on the cusp of Disillusionment?
Yes and no. DevOps started with small groups of motivated, very technical, and industry changing individuals. They often came from internal development teams of software companies. Teams where ALM and Agile had already taken stronghold, but for these individuals it was not fast enough. They wanted more releases, more metrics, and higher quality. They are the innovators. And their approach was good for small organizations, but not necessarily sustainable for large.
DevOps now includes the conversations that are beyond trying to conform to the theoretically perfect team, but find tactical ways to build more efficient development operations step-by-step. For the innovators this transition is frustrating. But it is more than frustration, it impacts how ISVs price and sell their products, no more animated characters on your website. It changes the notoriety of the innovators. And even impacts the vibe at industry events.
It’s Bloody For Everyone
DevOps adoption in existing development shops is messy. People will quit, get fired, and frustration of all kinds will surface. But this storming and norming is a necessary part of modernization. Ironically in the DevOps movement the same has to happen. There needs to be a disruption of the disruption, and a honing of the early adopters energy into a more practical problem/solution based practice.
A Moving Target
First you have to accept a few things. One is that DevOps is a moving target. The outcome of DevOps are consistent, but there has been varying opinions on what it is, and it’s impact on the future of development. Some would have you believe it means IT disappears from development processes altogether. This is a common vision amongst the innovators. While others would have you believe it’s simply an evolution of ITSM, which IT still owns. Both are wrong by the way.
Beyond the opinions, there is no avoiding the fact that enterprises also have to move faster and at a higher quality. If they want to embrace the term DevOps or not, this simple goal will lead to an outcome that would be hard to distinguish from other DevOps shops. But enterprises do not make decisions in the same way bottom up DevOps teams do. Should they be left out for this reason? Should DevOps become a members only club? No.
Why the Disconnect?
The bleeding edge DevOps folks have been guilty of the cognitive bias, focalism. As a result of talking to like minded modern development people, the feeling is that DevOps is a widely accepted and used practice. But the reality is that not only is DevOps not even widely known, Agile is only now becoming an majority practice. If you were to sub-segment the market into only those who are in the business of software, even then, they get DevOps, but can’t adopt it on a whim, no matter the motivation.
Focalism then would lead to innovator frustration when they hear about enterprise DevOps as something new. And seeing companies approach DevOps with a lot of traditional processes, the same processes the innovators have been fighting. But no movement has reached early majority adoption without morphing into something quite different than it started. And maybe even splintered off into other very similar but different practices.
After you realize that DevOps is in flux, it makes it easier to understand, that for the innovators, DevOps is slowly becoming something they did not expect. They believed that the large development shops will reform themselves into hip fast moving groups. But for others, who are becoming more open to the idea; know they need modern development, know they cannot start from scratch, and know they need help.
The movement is the problem and the solution
The problem with DevOps in particular is that the movement includes culture as a key tenant. In fact you cannot separate DevOps from culture. But the definition of “culture” is something much different than it is commonly believed. The point is simple. You define culture, before it defines you, because culture happens no matter what.
Culture also means having a cause. And having a cause is important to push and sustain DevOps. But really when it comes to results it doesn’t matter at all, because the pieces of the puzzle: analytics, pipeline, infrastructure as code, continuous integration, continuous delivery etc. are about solutions to real problems. Does the new practice provide value? Do more releases help your product? Is your software quality increasing?
Eventually companies will try and fail to sustain, and have a completely integrated environment without culture. In a perfect world they would start with culture, but the reality is they do not have to start there necessarily.
Moving the needle is all that matters
Getting more companies on-board with DevOps helps everyone. It fights the real enemy which is time, and quality. Let us not forget that the practice of DevOps has been around for a while. Large organizations even have teams called DevOps, or similar concepts such as “Shared Services”.
I do believe we are on the cusp of disillusionment for the innovators and early adopters. We are entering a time where the emphasis is on DevOps wins, more doing and less talking, and finding ways to reconcile heavy enterprise practices with modern development – in a way that does not slow it down. These are new problems that the innovators did not really consider.
A world where reports on “Cool” vendors are no longer relevant, and any conversation about technology that has not been used, will carry little weight. As we adapt, I hope the innovators keep pushing the needle forward, and support the path of greater adoption, over being a giant fish in a very small pond.
Those who are just entering will see this moment as a good thing. A “maturity”, although I hate that word, of sorts. This is where the enterprises start to get confidence. And adoption in part or whole of the DevOps framework approaches early majority, but with demonstrable success for the majority. No movement is without some spilt blood. And through the pain will come a better practice with better adoption.