How to Make Everyone Understand What DevOps Really Is
Learn about the three lean principles underpinning DevOps philosophy and culture, enabling faster time to market and better quality software.
Join the DZone community and get the full member experience.Join For Free
Even after years of the concept's existence, why is it so misunderstood? I think that I've already heard all of the explanations, but for me, there's a simple one, the only one that captures the essential meaning: the objective of DevOps is to minimize the time to market in order to deliver value to customers sooner.
A Wake-Up Call
Imagine how much effort a company must have to meet that goal. It's about using the right practices and tools, but beyond that, and most important, it's about building the right culture. And that's not the responsibility of IT alone; the main pre-req of the adoption of DevOps is the commitment of the entire company to reach that goal!
Unless the C-level guys understand it and foster the transformation as a whole, the company might have just a kind of DevOps. Worse, it may not accomplish the goal if all the effort is concentrated only in the IT department. Should DevOps start inside IT? For sure, and actually, that's what usually happens. However, without scaling the adoption to the company, there's no guarantee of getting all the benefits.
The Three DevOps Principles
After making this sort of wake-up call for positioning DevOps as a corporate issue, let me go deep in the concept a little bit more. Well, DevOps, influenced by the Toyota Way philosophy and the Lean movement, is underpinned by three principles, the three ways: flow optimization (first way), fast feedback loops (second way) and continuous learning (third way). The picture below shows the three ways.
1) Flow Optimization
The first way, flow optimization, aims to eliminate waste, bottlenecks within the process, handoffs between specialized teams, wait times. Automation is the key, extensively used to implement practices such as continuous integration, continuous delivery, and continuous deployment. The customer needs must be met as soon as possible, once it was identified by the business.
Notice that's about the whole process, from the identification of a customer need (left) to the point when the need is met (right). In other words, from the moment the demand has born until the new software feature is deployed into production. In fact, the item work moves into its workstream throughout different teams of several departments, including but not exclusively IT.
2) Fast Feedback Loops
The second way, fast feedback loops, aims to solve problems upfront, measuring the whole process, testing everything, alerting right when a failure is detected. Monitoring is the key, enabling fast feedbacks concerning the quality of the software, as well as its delivering, and above all, its value to customers. The second way follows the idea behind the Toyota Andon Cord.
Notice that quality is the responsibility of everyone throughout the process, not only a QA team role. The quality is measured from the beginning and, after all, must bring value to the customers. Feedback is constantly generating relevant information, including those ones that assess new features. This means that features can be withdrawn if they don't represent real value to the customers. With fast feedbacks, the business can also fail fast, and pivot, if needed.
3) Continuous Learning
The third way, continuous learning, aims to generate knowledge through experimentation. Instead of assuming everything is on the right path, assumptions are made, in order to be proven. The whole system is subject to improvement, to adaptation. The third way follows the idea behind the scientific method.
Notice that it requires a good dose of humility, flexibility, and courage. Humility, because the company must accept that is not always right; flexibility, because the company must be able to change; and courage, because the company must take risks. That's all about getting rid of the culture of blame and leveraging the collaboration and the sharing of knowledge.
If anyone asks you what DevOps is, or asks you to make a presentation about, please tell the complete story. Don't make the mistake of avoiding the tough part that DevOps requires a culture transformation. Yes, I know, everyone wants to learn the practices and tools to be more agile, but you must show them that they have to change their mindset beforehand. There's no way out.
Published at DZone with permission of Gustavo Carmo. See the original article here.
Opinions expressed by DZone contributors are their own.