A DevOps enabled workflow comes out of a culture that focuses on improving flow. DevOps answers “why”, and the choices around tooling and software answer “how”. You can’t have one without the other.
DevOps answers “why”
In our previous post we looked at What is DevOps? DevOps isn’t a tool you can buy. When you start with a blameless culture, continual learning, and open communication, the choices around processes and tooling become obvious. You’re collectively removing friction, improving flow, and increasing motivation among the team members.
DevOps is about making work transparent and improving communication. In a DevOps enabled workflow, developers tasked with building the application have input at the planning stage. And the operations team aren’t surprised at the point of deployment because they understand the business value and they have given input into what will make this deployment smoother.
The popular DevOps “infinity loop” diagram shows how feedback flows back into the planning phase, and suggests improvements for the next time. How teams do that, with what tools and processes, arises from that initial conversation and the culture that supports it. When teams work together in a DevOps enabled workflow, they discover “How can I make this better for you?” and “How can I help you be successful?”
Developers enjoy talking about the tools and software. Talking about the details of management culture and communication is harder. DevOps improvements start with a change in culture and mindset before you can decide on process or tooling.
When things go wrong, everyone involved in designing, creating, and deploying the software wants to solve problems and prevent them from happening again. With a DevOps mindset you practice collective accountability. This means instead of blaming individuals, teams focus on solving problems, while learning from them, and mitigating the risk of them happening again. And they collectivity share the responsibility for all of it.
If you compare a siloed culture to a DevOps culture, the software delivery cycle can be fraught with miscommunication and misdirection. Development and operations teams can be at odds with each other. Hand-offs are a weak point. The “works on my machine” attitude deflects blame, but doesn’t fix anything. Using standardized local dev environments that mirror the production environment as closely as possible are one way to mitigate this risk. This simple solution requires a change in process and in tooling, and then materially supports a culture of blameless continual learning.
DevOps answers the “why” behind the process and tooling choices you make. And the tooling choices answer “how.”
DevOps culture informs tooling choices
Whether it’s automation, testing, or configuration management, the tools and software are going to change over time and based on your specific needs and projects. Maybe a few years ago you were debating whether to use Chef, Ansible, or Puppet for configuration management with virtual machines. Today you’re thinking of leaving virtual machines behind completely, and moving to container based tools. But you have to keep in mind the reason you started looking at configuration management in the first place to reduce friction and get everyone pulling in the same direction.
With a DevOps enabled culture, teams look to each other to see how they can make it better for the other teams, and how they can help each other be successful. Digital agencies who use content management systems like Drupal and TYPO3, started turning configuration into code so changes should be tested, shared, and managed easily. In this way, they eliminated manual steps. They turned tasks into scripts that are automated, tested, and run reliably at the point of deployment. That is how you end up looking at automating systems so they are testable, deploy automatically, and scale.
Imagine how different your approach to tooling and process would be if you’re at a company that produces a single SaaS product or if you’re at a large enterprise that delivers multiple distributed and cloud applications. Your concerns about your users (customers v staff) are different. Your pipelines and workflows will be different. If you’re a digital agency, managing the sites of hundreds of clients on a handful of different CMS versions on different hosts and rolling out critical security fixes at short notice, you have a different perspective again.
The software you use to get your work done, and the processes you design may change but the principles of DevOps persist no matter what you’re using. With that said, the tools you use can either impede or enable DevOps practices.
Tooling affects what is possible
Early on in the DevOps movement, proponents started addressing a common myth or misconception that DevOps is a set of tools. You may be familiar with this popular quote from Chef CTO Adam Jacob: “DevOps is a cultural and professional movement.” (Velocity Conf 2010.) There’s no mention of the tooling or processes at all.
That doesn’t seem to be the full picture. If you overlook the features of your tools you overlook what product designers call “affordances.” A spoon can scoop, a knife can cut. For example, there are tools (and approaches to using them) that enable better communication and increased empathy. The standardization and scalability of Docker containers has been recognized as one of those solutions.
Containerization is affecting organizations even beyond the original “development” and “operations” teams they were originally designed for. Jérôme Petazzoni, tech support and Docker trainer pointed out how Docker fixed many problems inherent in tech support. It was no longer a matter of ‘works for me,’ or ‘can’t reproduce.’ Docker is a technical means to “foster empathy between teams, and break down silos.”
Another example is standardization and standard work. This concept underpins a key concept of DevOps: continuous improvement, also called Kaizen. Taiichi Ohno, the founder of the Toyota Production System on which Lean principles (one of the ancestors of DevOps) is based said, “Where there is no Standard there can be no Kaizen.” This means best practices are detailed and communicated. That includes as much of how you do things, why it’s done that way, and what you can do to improve the current practice. Without a consistently communicated and applied standard, how can you have a conversation about improving anything? This is why standardization is such a basic principle to DevOps that it’s easy to overlook. Without using standardized tools, scripts, monitoring, you can’t share and learn from other other.
Tooling choices also give teams some degree of autonomy, to create culture shifts from the bottom-up. Steve Grandchamp, DRUD CEO understands developers often find it easier to control tooling choices and it’s up to managers in the organization to lead bigger, cultural change. “We can control the tools we use and the impact they have on us. While culture change in the organization might have to be top down to connect business owners to tech owners, we can take control of this step and begin our own internal transformation. We can lead, and this is a very good first step.”
DevOps is culture and software. The choices around tooling and process should be a result of the culture; and by the same token, what is possible is limited by the capabilities of the tools. As a cultural movement, DevOps is focused on getting the development and operations teams collaborating to improve the flow of work. However, you can’t have one without the other.
DevOps is about breaking down silos. With a DevOps mindset you’re starting from a position of empathy. You share collective responsibility for failures, you look across teams and consider how you can help others, because you are operating as one. When you look at the value stream from idea to production, you can identify where there’s rework, waste, and time lost. This mindset directly affects your bottom line, and that’s why DevOps matters for digital transformation.