Originally ghost-written as Sanjay Gidwani for the Enterprisers Project
The principles of DevOps go beyond just improving software development processes. They also help foster stronger, more productive teams
Perhaps the most influential development philosophy of the last decade, DevOps brings together insights in psychology, sociology, technology, and economics, enabling IT teams to help digital businesses thrive. DevOps practices have played a key role in the success of organizations from AWS to Netflix.
How to empower and engage DevOps teams
The Three Ways offer a great deal of wisdom about how to help your team feel deeply engaged and satisfied in the creative process of delivering software.
Flow: Why it’s important
The first principle, Flow, points to the practice of continuous delivery and the importance of being able to expedite changes to users in production.For most DevOps teams, continuous delivery is the most important initial step they can take.
Most of the attention on DevOps has focused on this first aspect: implementing version control and automating builds, tests, and deployments so that teams can move more quickly. These practices are known as continuous delivery, and for most teams, this is the most important initial step they can take.
Version control provides a clear history of changes, which are ideally well-documented to help future maintainers. Automating builds, tests, and deployments allows the repetitive parts of the development process to be done by computers, reducing delays and freeing team members for higher-value work.
Why is that important? It gives developers a sense of meaning; they are delivering something valuable to end users. Flow focuses on removing waste, inefficiencies, and toil from development processes, which enables teams to build and deploy so that changes can be released quickly and painlessly. This is satisfying for developers and beneficial for end users and companies because it enables features and bug fixes to be released without delays.
The second way, Feedback, builds on continuous delivery, which is incomplete without it. Feedback requires your teams to build sensitivity and awareness into every aspect of the systems they support: You need feedback from people in your production orgs. And you need the systems you build to provide appropriate metrics that allow you to monitor and observe them in case of difficulties.
Feedback also implies that you’re gathering metrics on the development process itself – for example, by measuring the four key metrics of DevOps and any other important development metrics.
Because operations teams handle problems like excessive CPU load and lack of disk space, monitoring systems are of particular interest to system admins, database admins and their ilk. As teams have moved to web-scale distributed systems, the need for intelligible metrics and high-value notifications has become paramount.
Ops teams began instrumenting at scale with projects like Netflix Atlas, which in 2014 was tracking and aggregating 1.2 billion separate time series graphs. More importantly, these systems are managed by fewer than 100 engineers at Netflix, which shows their focus on isolating only the most important notifications from within that ocean of data.
The first way, Flow, is like the efferent nerves and muscles that allow our bodies to move and engage in conscious action. The second way, Feedback, is like the afferent nerves that allow us to experience and sense the world around us. That analogy makes it clear why the third way is Continuous Learning and Improvement.
Continuous learning and improvement
A systems point of view allows everyone to operate in an uncertain environment and focus on practical solutions over blame.
Teams need feedback to understand if they’re moving in the right direction or if they need to adjust. This learning process is the consummation of the previous two ways: Flow causes change, and feedback observes what happened, which is especially helpful when results are unexpected. The third way, Continuous Learning and Improvement, then helps teams make any necessary changes to improve results.
It’s the third way that truly unites Dev and Ops teams, based on their need to work together. New software updates can trigger high CPU loads, for example, which alerts the Ops teams. Or changes to the IT stack on the Ops side might limit or expand the options for development teams.
Most important is the net impact on customers, and a systems point of view that allows everyone to operate in an uncertain environment and to focus on practical solutions over blame.
How to build this thinking into team culture
This approach may sound like common sense, but the IT industry is still in the early days of implementing it. Adopting these practices requires investment of time and energy in building appropriate tooling. It also involves a shift from a power-oriented or bureaucratic culture to one that focuses on success and gives individual contributors autonomy to act, gain experience, and learn.
One thing that differentiates knowledge work from manual labor and other traditional jobs is the fact that knowledge workers often know more about the subject matter than their managers do. That’s simply because knowledge workers are more directly involved in the hands-on processes. Managers may have experience, but are they are usually more distant from the systems being developed than are those they manage. If managers lack the knowledge needed to direct things in a hierarchical way, they must delegate responsibility to individuals to act, observe, learn, and share.
What could be more human than having the autonomy to act, observe, and learn how to improve rather than simply following directions?
This is how the principles of DevOps helps teams, especially software delivery teams, foster each member’s potential, help them to find satisfaction and meaning, and deliver greater benefit to their business in the process.