DevOps: Getting it Right from the Start


The founder of discusses the generational inflection point we’re seeing in enterprise IT—and how to stay ahead of the curve.

By Brian McDonough
October 5, 2015

DevOps is changing the way software—and business value—is being delivered, and it seems to be gaining traction even faster than the Agile movement before it, catching some IT executives by surprise.

The fast-growing movement focuses on breaking down silos, not only extending the speed and flexibility of Agile practices, but maximizing business value of an application, from its initial conception to its delivery to end users.

To understand how DevOps works not only for digital-native “unicorn” companies like Spotify, Google and Twitter, but everyday horses like WalMart and GE, iRise Velocity talked to Alan Shimel, the founder and editor in chief of, the premiere hub for DevOps thinking. The site recently launched “The Leadership Suite,” focusing on executive-level discussions.

In our half-hour chat, Shimel focused on the big picture, telling us that DevOps is part of a massive change, an inflection point in how software is made and consumed.

Q: At a broad, high level, what makes DevOps more than just a new collection of tools and processes?

Shimel: DevOps is an umbrella term for something that’s more than Dev-plus-Ops. It’s inclusive, not exclusive of the business. It describes this new way we’re working together to define, develop and deliver software, and to touch customers. Anything that facilitates this way of doing it falls under this nebulous umbrella.

What we’re really talking about is a generational boundary point in the way we’re delivering and using software. We’re now in an app-centric world, with cloud and virtualization, mobility, big data; everything we’re doing is changed. This happens once every 15 or 20 years.

Q: How exactly does Agile fit with DevOps?

Shimel: Agile is being subsumed as part of it. Agile was very focused on the development zone, but now we’re seeing Agile for Ops, and how we take principles like lean manufacturing and mix them with Agile.

Q: Historically, many Agile practitioners have been anti-documentation, and even anti-prototyping. Yet we’ve seen these “pure” Agile principles don’t always scale well for the enterprise. Does this continue into DevOps?

Shimel: It shouldn’t. Look, anyone who’s anti-documentation is full of crap. There’s a difference between going fast and automating versus flying by the seat of your pants. In DevOps, the developer doesn’t just become the alpha dog, and everyone bends to his or her wishes. That is why culture is such an important piece, if not the most important part, of DevOps. It is a team effort and without documentation, it is very hard for the team to stay abreast of rapid changes.

If you’re going to automate and go fast, you’ve got to start with planning and objectives. It’s about shifting the “agility” ahead of the dev cycles. Prototyping, and anything that allows us to “shift left” in that classic process diagram, will set you up for success later. No DevOps folks I’ve spoken to disagree with that.

“That’s the key to DevOps: Cross-functional teams break down silos and reduce finger-pointing, all to make software creation and deployment go faster, better.”

Q: So product definition has a strong role in DevOps; what about QA, which can sometimes be maligned as a bottleneck?

Shimel: I talk to a lot of people through No one has the nerve to say, “I don’t have time for documentation, and we got rid of QA too, so now our customers are our guinea pigs.” Two years ago, you heard that, but it’s been discredited; no one wants to do that anymore. That doesn’t work.

Q: Why is that perception changing? Is the DevOps community more pragmatic than the early Agile adopters?

Shimel: I wouldn’t say that. What you get in the DevOps world are a lot more cross-functional teams, rather than Agile’s being strictly—or strongly—dev-centric. A DevOps team maybe developer-led, but theoretically everyone gets a seat at the table. So many large companies now have DevOps teams. It’s not that people are “DevOps engineers” per se. They’re cross-functional teams where devs are at same table with the ops, sec, QA and project management people. That’s the key to DevOps: Cross-functional teams break down silos and reduce finger-pointing, all to make software creation and deployment go faster, better.

DevOps hinges on how to roll out culture change more than on any individual process or tool. It’s about changing how we all interact with each other, breaking down the different silos, including business stakeholders.

Q: DevOps hasn’t been around nearly as long as Agile—where are we in the lifecycle, or hype cycle, of this movement?

Shimel: If you’ve read the book Crossing the Chasm, the technology adoption lifecycle model it outlines is exactly how I look at it. I launched in March of 2014, and started working on it around October 2013. At that time, DevOps was on other side of the chasm. It had the 15% of the market that’s early adopters, the people who are the first on their block to have an Apple Watch. In the last year, year and a half, DevOps has definitely crossed the chasm from early adopters to the early mainstream. That’s 35% of the market, people who say, “DevOps, Shmevops. I don’t care what it’s called—I’ve got a problem and if this solves it, I’ll use it.”

That’s where we are today. The next adoption phase is when we get the other half of the mainstream, another 35%, who are a little more conservative, and won’t adopt until a competitor or peer is successful with it.

Q: For this early 35% that just wants to solve a problem—what problem would they say DevOps is solving?

Shimel: They’re grappling with a new business environment, where everything is basically an app. It’s what Marc Andreessen said with Software is Eating the World: that every company is a software company, whatever their business. To compete, you’ve got to produce better software faster, and if you’re not, you can damn well bet your competitor is. Software is the lifeblood of your company.