Is DevOps becoming the buzzword du jour?
“Not that there’s anything wrong with that” — Jerry Seinfeld
[Disclaimer: The views are my own and do not reflect the views of the company I work for]
Because there’s a lot of ink being spilled on this topic, I’ve begun to reflect on what I’ve learned in the last few months. What does it mean to be a product manager for DevOps? What should we deliver? Is there such a thing as a “DevOps product”? To the last question at least, I’ve decided that the answer is no. There’s no DevOps product just like there is no agile product.
For example: Jira is an issue tracking and project management tool. Atlassian did not build an “agile” product.
DevOps also has been often referred to as an extension of agile.
Agile is a methodology and answers the following needs:
How should we as individuals work together to build software?
Focused on team collaboration including customers
It’s explicitly not process or tools
DevOps is a development practice and answers the following needs:
How fast are we able to deliver value to customers?
Focused on the software’s deployment velocity
It’s not process or tools or products
Gene Kim describes software development in a manufacturing context in his book — “The Phoenix Project”. Manufacturing is the practice of producing goods. DevOps is the practice of accelerating the production of software. The goods from manufacturing are things that we expect to use. We wouldn’t produce things that aren’t going to be used. Similarly, software has to be delivered in production for it to be used — assuming of course, that we are building it for the right users and validating our hypotheses continuously via data-driven experiments. DevOps is about delivering software at the speed of business.
Adrian Cockcroft (Netflix, Battery Ventures) focused on speed even if it’s at the cost of some efficiency. “Speed wins in the marketplace”.
Software has to be designed to remove dependencies, which improves speed, quality, and reduces risk. How? By breaking applications down into their smallest components to make speed happen. If things go wrong and they surely will, then only that small component can be rolled back or updated (rolled forward). Recovering from failure quickly is a lot more important. The teams building other components can continue delivering value. In modern software development, the “code” is deployed any time/all the time. When to “ship” it — make it available to end users — is a business decision. In that sense, speed is relative and for certain apps or micro-service, it may be daily and for others, it may be weekly, monthly, or even quarterly.
DevOps has been described as — people, process, and technology. We need to re-think this. Let’s take each one of these terms:
Technology:
DevOps is agnostic of the technology used. There are many OSS (Open Source Software) or non-OSS tools that enterprises use. Vendor claims about having a “DevOps tool” or “DevOps product” doesn’t make sense. When we talk about technology, it should be in the context of building software regardless of whether it’s fast or slow, agile or waterfall or somewhere in between. In other words, regardless of the practice or methodology, just don’t call it a “DevOps ……” (your product name here). Technology provided to people involved in a DevOps practice of delivering value to users should help them eliminate manual steps wherever possible. Make it simple, automate everything, and make it programmatic so it can be extended.
Process:
Agile is a methodology, and neither agile or DevOps is a “process”. What methodology or process customers use is up to them. Agile prizes collaboration over process. DevOps practice enables faster software delivery by collaborative teams. Everything in the world has something to do with people and process. DevOps is not unique here. This leads to the last one.
People:
When we discuss people in a DevOps context, it’s about the “culture”. There’s a lot of talk about “changing” the culture. What does changing the culture mean? Is it changing the culture of the organization? This is a very big change and not too many enterprises would be able to do that easily or quickly. When we discuss a “culture” change, it needs to be very specific to the practice of software development. It should start with a particular app (i.e. service). The team building the service should be empowered to experiment and learn quickly. Newer technology companies with a singular product focus have an easier time building this culture for the entire organization. Enterprises can start with small teams and a few services to change the culture from the bottom up.
Culture enables speed:
Why is speed important? Time to market is the biggest driver for speed. Organizations should boldly embrace speed to achieve continuous innovation. They should feel it in their bones. They should:
“feel the need, the need for speed” — Maverick & Goose, Top Gun.
“I feel the need, the need for speed”
How to achieve speed in software development? Enable software systems to change continuously to meet market demands. To build a resilient system with speed, quality, and security would naturally move us towards a cloud-native, micro-services architecture. This will enable collaborative teams to work autonomously and take ownership from development to delivery. Software delivery will be in Docker containers running on structured platforms (PaaS). Speed demands continuous innovation. Make speed your friend. If you don’t feel the need, you can still be agile. The world is changing fast so it’s not enough to be agile, enterprises must build software much faster. When it comes to delivering value through software, it’s not just about how but how fast. Remember:
Software is eating the world — Marc Andreessen
And it’s happening much faster.
If we have to use three words to describe DevOps, I would suggest:
Culture — Enabling continuous innovation through software development
People — The team building a specific service (app)
Practice — How fast are they delivering value to customers
Why use three words when we can use one — practice. To simplify:
DevOps is the practice of accelerating software delivery.
This means that companies delivering technology solutions are not providing “DevOps tools”, “DevOps products”, etc, — rather we should be helping customers adopt DevOps practices. If someone is selling a “DevOps product”, run far, run fast!
Everything is about people, process, and technology these days so when we associate DevOps with these words, it is like saying why don’t we throw everything against the DevOps wall and see what sticks.
As a Product Manager, I want to deliver products that help teams accelerate the delivery of software without compromising quality. But please, don’t call it a “DevOps product”.
What do you think, are we getting sucked into the buzzword machinery?