DevOps is a term emerging from the collision of two major related trends.
The first was also called “agile system administration” or “agile operations” — with focus on applying newer Agile approaches to operations work.
This new “fashion” trend is making some companies abuse the Agile terminologies, making both Dev and Ops life miserable.
The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service.
DevOps sounds simple.
“It’s all about combining Dev and Ops — right?”, “Let’s create a DevOps team, recruit some DevOps engineers”, “Let’s buy some DevOps products and fix all our problems and achieve our goal.” Goal sounds pretty simple — deliver high quality high value software to the customers, as the best Continuous Delivery organisations do.
Most organisations these days seem to be saying that they aspire to this idea, though they don’t necessarily know what it is. Management use DevOps as allies in the cause of making software development better. How?
It implies that fixing a problem — the traditional barrier between Dev and Ops, is enough to achieve a goal of ‘perfect software’. But fixing the relationship between Dev and Ops is not a silver bullet. There are other significant barriers: the gap between the customers and business, business and technical teams, an even between technical teams (e.g. testers and developers).
What’s Really Important DevOps rarely says enough about the goal of delivering valuable software into the hands of users efficiently and reliably.
Not because they are wrong but because they focus on the mechanism rather than the goal. The problem is not really the fault of the originators of the local DevOps teams, but it’s more related to the overall idea. As with most ideas, people will often take a slick view and so miss the important details.
The business should be able to experiment with ideas and find what works best.
The root cause of the problem is that this is hard to accomplish. It requires a change in culture across the whole organisation. And there is no simple or universal solution. Adding a DevOps team is often just creating yet another element in non-flexible CD chain. The culture change that you really want is to make developers responsible for their code in production and operations people responsible for the design of code that can be maintained in production — collaborative teamwork with constant focus on the following aspects:
Analyse it. Analysing what you do, on a regular basis, and making it better.
Don’t be afraid of change. Dropping practices, technologies, even people, that don’t work and replacing them with ones that do.
Don’t be a copycat. Do not follow the way “we always do it that way” or “we must do that because this worked for Fortune 500 company”. This is simply no place for copycatting. Completely the reverse: only rationalisation and experiments.
You should always keep in mind The First Principle of the Agile Manifesto:
“ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
Take a look at your cycle-time, from “idea” to “valuable software in the hands of your users”. Analyse it. If the barrier between Dev and Ops is a significant one for your organisation, this analysis will highlight it and give you the understanding to begin to change things.
Conclusion You Don’t Need a DevOps Team. What you really need is a holistic approach to software development. Yes. it’s not an easy route. It takes a long time for teams to get good at these things and it will affect the way in which you organize your company, not just your development or operations functions. You’ll be surprised at the end — your organisation’ll get to the high ground of effective process. The one that best fits your needs. So break down barriers, increase automation, bring collaboration and iterate.