“DevOps” is an interesting term. It is a bit like the word “accountability.” Everyone agrees it is important, but it means different things to different people. That, of course, is partly what makes it so popular.
If nothing else, the DevOps movement is a call for change, but that change looks different depending on which level of the organization is the target.
At the technical process level, we can understand DevOps the way it got started, in the context of Continuous Delivery. A project is accustomed to deploying big batch releases once every quarter or so. DevOps is the aspiration to achieve much more frequent deployments.
At the team level, we can understand it as an emphasis on silo-smashing IT collaboration. Our developers, testers and operations teams need to work more closely together, day-to-day, in the flow of the projects.
(Related: How DevOps culture works)
From an organizational perspective, DevOps improvement is best understood through the Lean perspective: emphasis should be on measurement and continuous improvement through things like the identification and removal of constraints on system flow.
Changes at each level are interlocking. Systemic improvement by an organization requires cross-functional collaboration at the team level, which tends to operate through discrete Continuous Delivery tools and practices.
Uniting these levels of change is the call for improved organizational culture. It is fair to say that no matter how many new processes or tools are introduced, if the culture of the organization is suspicious of or hostile to change, DevOps will not happen.
But even that isn’t the end of the story. What’s missing is the motivation, because it is also fair to say if there is no compelling, motivating factor to radically improve software delivery, DevOps will not happen either.
DevOps, and software delivery in general, is simply a means to an end: an attempt to match an internal or external customer need with a product or service.
So much attention and focus in the software development field is around building the product right. That is, using correct practices and architectural patterns to drive down defect counts, to facilitate code reuse, or to minimize response time. DevOps is primarily in the service of building the right product: getting software out the door and into the hands of users (and then learning from them). What you learn is generally one of three things: 1) the product is right as is (which never happens); 2) the product is close but needs some changes; or 3) the product is badly wrong, a waste of time, and should be scrapped.
If this sounds straight out of Eric Ries’ “The Lean Startup,” it is. The idea of the minimum viable product, an incremental deliverable designed for high-risk business environments, is much more broadly applicable than it seems at first glance.
In fact, almost all software development is expensive and high-risk, and should be treated in similar incremental fashion. Enterprise migrations are some of the most expensive, highest-risk projects in IT, and few are treated using an MVP approach, where value is delivered incrementally, beginning almost immediately after project inception.
In all the buzz around DevOps, it can be easy to lose sight of the fact that this movement is an extension of agile development practices, carrying agile principles into the operational domain such that the deployment environment is ready to accommodate the frequency and speed of application change. That change should be a user-driven process, however. In other words, the business should be driving and demanding it.
By matching customer needs with the delivered product, you help mitigate uncertainty and risk, give yourself the opportunity to adapt the project to changing requirements, and get an opportunity to learn and exploit that learning in real-time as the project progresses.
Those are advantages nearly any organization should want when embarking on a change initiative, particularly one in IT, regardless of the competitive landscape around them. DevOps is an opportunity to bring software development closer to the business, closer to the mission, and closer to the customer, where it belongs.
