Table of contents

What are the “Three Ways”

  • The “Three Ways” are the principles from which all DevOps patterns can be derived.
  • They are presented in the books The DevOps Handbook and The Phoenix Project.
  • They describe the values and philosophies that frame the processes, procedures, and practices of DevOps, as well as the prescriptive steps.

The First Way

First way of DevOps

  • Emphasizes the performance of the entire system, as opposed to the performance of a specific silo, work, or department.
  • Focuses on all the business value streams that are enabled by IT.
  • Begins when the requirements are identified and ends when the value is delivered to the customer as a service.

Outcomes of the First Way include

  • Never passing a known defect to downstream work centres.
  • Never allowing local optimization to create global degradation.
  • Always seeking to increase flow.
  • Making work visible and promoting understanding of the system. No one has complete visibility of a complex system.
  • Reducing batch sizes and intervals of work.

It also includes

  • Building in quality, testing everything early rather than late.
  • Constantly optimizing for global goals.
  • Continuous build, integration, test, and deployment processes.
  • Creating environments on demand.
  • Limiting work in progress.
  • Building systems and organizations that are safe to change.

Technical practices of flow

  • Enabling on‑demand creation of dev, test, and production environments.
  • Creating a single repository of truth for the entire system.
  • Making infrastructure easier to rebuild than to repair.
  • Modifying the definition of development “Done” to include running in production‑like environments.

The Second Way

Second way of DevOps

  • The Second Way is about creating right‑to‑left feedback loops.
  • It is not only about feedback but also about feed‑forward information loops.
  • The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be made continually and quickly.

Based on Dr. Steven Spear’s work on designing perfectly safe systems

According to Dr. Spear, a complex system can be made safer to work in when the following four conditions are met:

  • Complex work is managed so that problems in design and operations are revealed.
  • Problems are swarmed and solved, resulting in rapid construction of new knowledge.
  • New local knowledge is exploited globally throughout the organization.
  • Leaders create other leaders who continually grow these types of capabilities.

Outcomes of the Second Way

  • Identifying, understanding, and responding to all customers, internal and external.
  • Embedding knowledge where it is needed.
  • Shortening and amplifying feedback to enable faster detection and recovery.
  • Ensuring a fast and constant flow of feedback from right to left at all stages of the value stream.
  • Discovering problems as they occur and swarming them until effective countermeasures are in place.

Technical practices of feedback

  • Creating telemetry to enable seeing and solving problems.
  • Using telemetry to better anticipate problems and achieve goals.
  • Integrating hypothesis‑driven development and A/B testing into daily work.
  • Integrating user research and feedback into the work of product teams.
  • Enabling feedback so Dev and Ops can safely perform deployments.
  • Enabling feedback to increase the quality of work through peer reviews and pair programming.
  • Enabling feature deactivation with switches when features are found problematic.

Third Way

Third way of DevOps

The Third Way is about creating a culture that fosters two things:

  • Continual experimentation, taking risks, and learning from failure.
  • Understanding that repetition and practice are the prerequisites to mastery.

Outcomes of the Third Way

  • All participants need to allocate some time for the improvement of their daily work.
  • This includes Ops, Security, and Compliance people.
  • Creation of a generative, high‑trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk‑taking.
  • Creation of organizational learning from both successes and failures.
  • Due to short and amplified feedback loops, ever‑safer systems of work are created, allowing risk to be reduced during experimentation and learning to happen faster than the competition.

Technical practices of continual learning and experimentation

  • Establishing a just, blame‑free culture to make safety possible.
  • Scheduling blameless post‑mortem meetings after accidents occur.
  • Injecting production failures to create resilience.
  • Decreasing incident tolerances to find ever‑weaker failure signals.
  • Redefining failure and encouraging calculated risk‑taking.
  • Converting local discoveries into global improvement.
  • Reserving time to create organizational improvements and learning.
  • Instituting DR dry runs to rehearse failures.
  • Building reusable operations user stories into development, standardizing and automating Ops‑related tasks.

How the various stakeholders are affected by the Three Ways

  • Development practices (Agile) are the closest of all stakeholder groups to the DevOps principles.
  • Operations people are usually not used to frequent changes in their toolchain and processes, although they can converge relatively quickly to DevOps principles by leveraging available tooling.
  • InfoSec people are used to testing after release; any problems found are reported to be included in the next iteration, which is usually too late. By using the DevOps approach, InfoSec happens as part of regular development, finding issues early and fast with enough time to fix them.
  • Compliance people are the most remote from DevOps practices. They usually keep their processes in document‑oriented formats (Word, Excel). There are tools today that allow these documents to be expressed as BDD‑type tests and executed alongside regular integration tests.