What Is DevOps? What Is Agile?

This article is for all the executives who have heard about Agile and DevOps, but are—unsurprisingly—confused by what they hear: because, frankly, Agile and DevOps are radically different from traditional approaches, and—frankly—it is explained pretty poorly by the Agile and DevOps communities, with strange lingo and even a little bit of arrogance.

So I am going to explain it for the uninitiated. With standard terminology. Without dogma, or purism. In practical common sense terms that will make sense to a business person.

Agile is your friend. Don't be afraid of it. It can help you greatly. Agile is also not a new thing: only the label "Agile" is relatively new, dating from the late '90s. Agile is actually a collection of ideas that attempt to take us back to what used to work well. During the 1990s, IT went through a methodology craze, and people tried to turn IT project management into a cookbook kind of process: just create these documents, and all will be well. It did not work. The problem is, building software is not at all like other things: software is different every time, you can't look at it to see how done it is or how well it is put together, and it is also really difficult to define all of the requirements up front. So methodologies did not work well, and the larger the project, the higher likelihood of failure—with failure approaching 100% for large projects. Now what?

What did work was (1) building a little at a time, (2) showing what you built to the actual users and business stakeholders, to see if you got it right; (3) pivoting, because users often change their mind when they see something working, and also because circumstances can change, and (4) not trusting claims that a "design is done" or indeed anything is done unless you can see tangible proof that you can understand—like a working feature in the system.

That's Agile. Notice that instead of creating a big plan in which we specify when we will build each feature, we leave it fluid. The Project Management Institute calls this rolling wave planning: yes, create a long term roadmap, but don't trust it. Only plan at a detail level for the things that are next to be worked on. For anything else, keep it sketchy and allow it to change over time—expect it to change.

Now there is another view of what Agile is: If you hire Agile coaches, they will probably tell you that you need to set up Scrum teams, and create team rooms where everyone sits together, and they will also tell you that you need to meet with them regularly and create user stories. Those are fine practices, but those things don't define Agile. You can change them, and still be Agile. Agile is a way of approaching things, as I have described above: small increments, only trust what actually works, etc., look at the product as it evolves, etc. That's what Agile is, and you can invent your own way to achieve it. If you like, Agile is actually defined on a website: AgileManifesto.org. That site was created by seventeen highly experienced people—people with gray hair, programmers. People who had seen how things had gone wrong in IT, and wanted to get back to what works. Check it out. That is what Agile is. It is not a methodology, and it is not Scrum: it is a philosophy for how to approach software development so that it yields the best results for the business.

Now you might also hear about DevOps.

No one came up with DevOps, defined it, and people started doing it. What happened was that companies like Amazon, Google, Netflix and others discovered that they had problems, and Agile didn't address those problems, so they found their own solutions. Those solutions came to be known collectively as DevOps, and later, Gene Kim wrote up some over-arching ideas that seemed to explain how the Googles and Amazons were approaching things. He called it the three ways.

So now you see that Agile is not the full picture—there is more to building software. DevOps tries to fill those gaps. What are the gaps?

The main gap that Agile left open was that it was entirely focused on the development team. However, in a large organization, a team does not exist by itself: it relies on many things that the organization provides. In fact, to even deploy software for production use, there are other groups that need to be involved along the way—the earlier the better. That's what DevOps is about: how to enable Agile teams within an organization.

You might think that this sounds like DevOps is "all the technical stuff", and that you don't need to concern yourself with it. You do, however, to a point. DevOps is what really enables Agile to work—you need to know what it is, and what it looks like, and what to ask for. In short, if you are a business stakeholder, you will want to make sure that your IT counterparts are using true Agile and DevOps methods so that you have the best results.

For example, does your organization perform automated integration testing? That is a DevOps practice, and it is really important if you want to release frequently, and also if you want to have a high quality system with few bugs. Does your organization use automated server provisioning, and is that available to the development teams, or do you instead have old-style "dev", "int", and "prod" environments, or something like that? Automated server provisioning is the key enabler for automated integration testing. Do your teams use "behavior-driven development"? That is another powerful enabler for automated integration testing—and so it is an important cornerstone for reliable applications that you can update frequently. Are your IT risk controls and procedures aligned with DevOps methods, so that you can manage risk without slowing things down or even blocking the new methods altogether?

You might think that DevOps is too technical for you, but it is possible to explain most of it in layman terms. I have done so many times. Understanding it is important so that you can understand what your teams are not doing, and what therefore needs to change if you want to obtain the benefits of DevOps and Agile.