DevOps —not unlike Lean and Agile— is a partial answer that contributes to the solving of a very complex problem. In difference to Lean and Agile, however, it does not try to distance itself from the underpinning technology and tools. I suspect, however, that we may soon abstract away from the original “Dev” and “Ops” notions of the problem. Here’s why…
DevOps is a #hashtag
At the Agile 2008 conference Andrew Shafer had planned to present a talk titled “Agile Infrastructure”. The only person who turned up was Patrick Debois, whom —at around the same time— was also involved with the “agile-sysadmin” mailing group started by Marcel Wegerman in Europe. After Patrick saw John Allspaw’s presentation titled “10+ Deploys per Day: Dev and Ops Cooperation” at Velocity 2009 —which, incidentally, is widely regarded as a pivotal moment for the DevOps movement— he was inspired to launch an event in Ghent in late 2009. The name of the event was somewhat arbitrarily descriptive of the intent to include developers (Dev) and operations (Ops) folk in a two-day conference (Days).
That first DevOpsDays event spawned some follow-up events with the same name in other countries, and also started the #DevOpsDays hashtag on Twitter. Of course, characters are a commodity on that particular social platform and it wasn’t long before people started using #DevOps instead. — See this presentation of “The History of DevOps” by Damon Edwards on IT Revolution Press for more. (Damon has been involved in the conversation as early as 2007.)
DevOps is a contributor to the Lean and Agile discussions
The best agreement and commonality you will find between proponents of DevOps over what it is, will be “DevOps is a movement” or “DevOps is a culture”, but the most concise description that I’ve come across (used by Gartner in a slide from March 2011) is that “DevOps is a strategy”.
The truth is that —as a strategy, culture or movement— DevOps is essentially a shift in focus and an increase in the scope of application for Agile. As noted before, the topic was very early on in this journey centered around Agile notions (e.g. “Agile Infrastructure” and “Agile System Administration”). The —very valuable— contribution that the DevOps thread brings to the table, however, is an awareness of the need to find a solution to implementing Lean principles and Agile practices over work centres that are traditionally extremely divergent in both their objectives and their approach. That, in turn, forces us to take a hard look at the significance of enterprise reliance on various IT elements over the business value streams.
When we start addressing those concerns, we start seeing the applicability of Lean principles to reduce waste and increase flow in a single work stream. We become empowered to continually improve when we apply principles of Kanban or other visual management techniques and realise that adding IT work to improve the flow of IT work is a Good Thing™ — vis-à-vis repaying technical debt, and creating a Kaizen culture.
Thus we draw closer to the true nature of DevOps as a contributor to the overarching Agile Transformation Strategy, where the latter holds the primary intent of driving towards Business Agility.
It’s not only Dev and Ops anymore
Throughout the last decade the (particularly pronounced) mismatch of the divergent vision, goals and approaches of development and operations —accentuated even more by the fact that they are parts of the same organisational area— has provided a useful focal point for a discussion that everyone could participate in. Most large enterprises have felt the pain of that mismatch to some degree and there is no shortage of horror stories about just how bad it can get if left unchecked. In classic chicken-and-egg fashion, more and more thought leaders joined the conversation, which gave rise to the DevOps movement, which in turn created more opportunity for thought leaders to unite around a common view of the problem. The resultant snowballing ethos has been a critical enabler for the groundbreaking work that has been accomplished, not only within the DevOps community, but also within Lean and Agile.
Some groans from the reader ensue… — “Agile has been tearing down these walls for many years!”
That is, of course, entirely correct. The very concept of an “Agile Development Team” was based on the inclusion of different functions —i.e. business analysis, development and quality assurance— into a single team. However, those were all functions that naturally row in the same direction, being to deliver a software product of one form or another. Agile hit a bump in the road when it got to IT Operations, and the DevOps conversation has been actively involved in solving that.
Of course —as soon as one begins to understand the solution to the “Development vs. Operations” problem in terms accessible to Lean and Agile thinking (terms like “work item type”, “technical debt”, “preventative maintenance”, “size”, “capacity”, “value stream”, “outcome”)— it naturally becomes apparent that you also have to include other areas, like Information Security. So some bandy about things like “DevSecOps”. But then you also have to include Business in the “single work stream” view… “BizDevOps”, anyone? “NetSecOps”. Etc.
In other words, as soon as you overcome the problems represented by the Development vs. Operations “wall”, it becomes natural to recognise other similar walls and to tear them down in similar fashion.
It’s neither a Dev thing, nor an Ops thing
It’s a management thing. More accurately, it’s a people thing. DevOps brings an awareness of why certain problems exist in areas where people are trying to contribute to a specific set of organisational objectives while their own objectives are not aligned with those of the enterprise. As long as CXO’s consider IT as a department that can be delegated away or outsourced, those behaviours will filter down into middle management to manifest as disconnected and divergent priorities being demanded of a pool of finite resources, and further down into the trenches to manifest in the form of fear based foxhole digging and other defensive habits. And that is a people thing.
Engineers, developers, analysts, designers, administrators… everyone wants to feel that they are a valuable contributor to the greater whole. DevOps helps us a long way towards understanding that. The solution is —quite simply— a leadership approach that enables people to feel valued by empowering them to contribute freely.
Don’t get me wrong, DevOps also fully helps us to see the value that technology and tools can bring when they are applied appropriately —and as such it is undoubtedly very closely coupled with technology— but it’s not about tools for the sake of tools. Instead, it requires leadership to have an understanding of how IT should be applied effectively (when to buy, when to build, when to fix), and simultaneously requires technologists to have an appreciation for interpreting business objectives, intent and priority.
In the context of the IT-enabled enterprise, this results in a shift that integrates IT into all the other reliant areas of the organisation. How far we develop that integration remains to be seen, but it is clear to me that DevOps is mostly an enabler for the next wave of progress towards true Business Agility — albeit a very important one.
In an earlier post, I all but bellowed from the rooftops how “DevOps is a Thing!” – so what is this, then? Well, context is everything, so…
- DevOps is a Thing when the “Thing” is a topic for discussion or an area of interest that brings together the tremendously good perspectives and contributions of expert thought leaders around the globe in useful ways so that they can be evaluated, applied, tested and discarded or implemented according to our own contextual requirements.
- Conversely, DevOps can never be a Thing where the “Thing” is a discipline or set of practices or tools that can be held up in isolation as an area of study or specialisation.
So, for anyone out there working to solve the “Development vs. Operations” problem in your own organisation, I maintain that DevOps is a Thing! You should keep at it, but only until you solve it.