Despite the name, DevOps is so much more than just smashing development and operations together. If you've ever worked at a company that has separate development and operations teams, where the process of releasing the product involves handing it off from one team to the other, then you've almost certainly felt the friction that results when things don't go according to plan. Fingers start pointing, blame gets placed, and morale and productivity suffer. In the two decades since DevOps became a thing, it has grown in momentum, rising to buzzword status, because as the name implies, it's meant to bridge that gap and eliminate the contention between Dev and Ops. Of course, buzzwords tend to spread faster than understanding.

Seeing things from multiple angles can help create a clear mental picture, so the people who are most likely to get it are people who have already worked as both developer and operator. I'd be willing to bet it's usually ops personnel with a strong programming background who are the most vocal proponents, because they feel the pain acutely, and have the experience and motivation to find a solution such as DevOps. In the eyes of business leaders, these cross-trained individuals become beacons of hope, so it makes sense for management to think, those DevOps guys have one honking great idea, let's hire more of that! Hence, we find pages upon pages of job postings for "DevOps Engineers" and the like. But DevOps isn't a position, and while adding the buzzword to your résumé may help get you hired, it's important to understand that there's more to DevOps than a cross-functional skillset in an individual.

When Patrick Debois and Andrew Schafer first discussed "Agile Infrastructure" way back in 2008, the conversation was based on the frustration around the stark differences in how development was done vs. operations, and the negative effects those differences can have on productivity and quality. By applying Agile concepts to the entire process end-to-end, from development all the way through deployment and operation of a product, this cohesion benefits both employee morale and the end result. Echoing that sentiment in 2009, Flickr employees John Allspaw and Paul Hammond demonstrated that a fully integrated approach with a cross-functional team working in unity toward the same goal was the only rational solution. DevOps was born, and rather than being a discipline or skill that could be applied by a single person in isolation, it was an attitude of teamwork, requiring buy-in from multiple levels in an organization.

As with many great ideas, the implications of DevOps go beyond the initial motivation for it. At its core, DevOps is more than just closing the gap between two organizational departments that traditionally tended to be at odds. It's about applying Agile principles to the entire process of releasing software, not just the development process. And more than just that, Agile and DevOps were both born out of a historical context in which Lean Manufacturing had become well-established. I think it's fair to say, then, that DevOps is really just the complete application of Agile and Lean principles across an organization and across the entire product lifecycle. To understand DevOps, one must understand Agile and Lean.

So what is it? Here's my working definition: DevOps is eliminating waste by emphasizing people over processes, delivering working software as quickly as possible, deferring decisions in order to respond to change, all while keeping the big picture in mind.

There's a lot packed in there, which makes sense when considering the volumes that have been written on Agile and Lean in themselves. I think it's safe to say that to "do DevOps" means to vigilantly improve, both as individuals and as organizations, to deepen understanding of the process of producing and releasing software, and to continuously integrate what you learn along the way into the culture and daily practices of your entire organization. This includes but is certainly not limited to integrating your development and operations teams; indeed, the extent of what DevOps means is not and perhaps never will be entirely known.