The DevOps Connection: Innovation is Both Technical and Organizational
“How long does it take to deploy your app from the time you first think of a feature to the moment it’s in front of a customer,” I asked? “In other words, what is the cycle time of your process?”
“Well, we can build anything very quickly. But deployment? You should talk to our DevOps team about that.”
Yeah, they’ve totally missed the point of DevOps.
In older organizations there are Operations teams, sure. And there are developers. And they are forever separate. But the rationale behind the DevOps movement is explicitly and intently to bring the operational responsibility of releasing, scaling, supporting applications on company infrastructure firmly into the hands of the teams that built the application.
Anything you’re doing that is called “DevOps” and yet separates responsibility of spinning up servers, writing testing automation and orchestration code, or managing uptime and reliability, from the responsibility of writing the code itself is in fact not DevOps at all.
Why does this matter? Allow me a metaphor. In the 1960s, student activists declared “the personal is the political”, unlocking previously unseen linkages between economic, racial, and gendered politics at the system level and the lived personal experience of individuals oppressed by that system. This mattered because real change has to occur at multiple levels of scale or abstraction at the same time in order to be effective. Change is systemic, but is experienced at the personal level.
In the same way, through the lens of innovation and continuous improvement, we could easily say that “the technical is organizational”, and vice versa. To innovate at all, moving at the speed of everyone’s ultimate competitor, (Amazon, Facebook, etc.), one needs to envision, design, develop, test, and deploy new services for customers faster and faster every year. The clock is ticking.
Teams can embrace Agile at the organization level. They can gain executive support, and they can work in small batches, and they can focus on the delivery of value to the customer. But if they are shipping software of any kind, and fail to observe the hallowed practices of extreme programming, including Test-Driven-Development, Continuous Integration, automated testing and deployment pipelines in the cloud, keeping code modular with SOLID principles and appropriate design patterns, all the organizational support and process improvement will not help them.
There is no difference conceptually between the cognitive flow achieved by the practice of the classic “Red, Green, Refactor” loop in Test-Driven Development from the vaunted learning engine of “Build, Measure, Learn”. They are simply operating at different levels of abstraction in the systematic delivery of value to customers. The very best high-performing teams in the world are simultaneously iterating at an organization and technical level; they are able to hold both levels of abstraction firmly in their attention at the same time.
Focus on just one, or just the other, at your extreme peril.
