“Not that there’s anything wrong with that.” — Jerry Seinfeld
Because there’s a lot of ink being spilled on the topic of DevOps, I’ve begun to reflect on what I’ve learned in the past 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. Let's consider both these terms.
Agile is a methodology:
- It addresses how we should work together to build software.
- It is focused on team collaboration, including customers.
- It’s explicitly not about process or tools.
By contrast, DevOps is a development practice.
- It addresses how fast we are able to deliver value to customers.
- It is focused on the software’s deployment velocity.
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—i.e., 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 at the cost of some efficiency:
“Speed wins in the marketplace."
Software has to be designed to remove dependencies, which improves speed and 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—only that small component is 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-services, it may be daily, while 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 a look at each of these terms.
Technology
DevOps is agnostic when it comes to 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” don’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 DevOps practices 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.
Let’s get back to 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,” as Maverick and Goose say in the movie Top Gun.
How do you achieve speed in software development? You enable software systems to change continuously to meet market demands. To build a resilient system with speed, quality, and security would naturally move us toward a cloud-native, micro-services architecture. This enables collaborative teams to work autonomously and take ownership from development to delivery. Software delivery is in 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. But the world is changing fast, so it’s not enough to just 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 ,” according to Marc Andreessen. And it’s happening fast.
DevOps definition: If we have to use three words
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 teams delivering value to customers
But 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 building 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? Is there such a thing as a DevOps product?
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
