The Zeroth Way Of DevOps

Take time to simplify and automate solutions: simple, automated systems cost less to maintain than big, manual ones, and take less work to make more useful outcomes.

That quote neatly sums up the Zeroth Way. Resolving the tension between traditional tools-clouds-and-apis DevOps and Kim's Three-Ways TOC philosophy, the Zeroth Way doesn't say either is wrong. It says both are right.

The Zeroth Way naturally connects DevOps' to XP because, twenty years ago, Extreme Programming gave a birth to what Kim rightly adopted as DevOps Second Way: Amplify Feedback Loops. Indeed we can see the second way as a proper superset of Don Wells' famous XP loops:

Refactoring as the Fundamental Way of DevOps

Though we have many venerable agile books on Refactoring, the word is often misused to mean re-writing, debugging or tweaking. SAFe goes so far as to reverse it, imagining refactoring should be "planned for, estimated, and prioritized" by a Product Owner (SAFe requires this quotation to say ? Scaled Agile, Inc. <FFS> don't think SAFe's copyright applies to the rest of this article, which, for the avoidance of doubt, is available to everyone in the world under a Creative Commons CC-BY-SA 4.0 International License </FFS>). But the original intent of refactoring comes from Kent Beck:

[refactoring is] the system expressing its own desire for simplicity. 

Beck's fellow extremo Ron Jeffries was careful to qualify the practice with the word "mercilessly" to make it clear that this is nothing like SAFe's game of tech-debt deferral, but a continuous and rigorous team discipline explicitly supported by quality automation and collective ownership (a.k.a. DVCS in these modern times).

Merciless Refactoring in DevOps means Dev proactively and systematically simplifying all the value, work and learning flows in Ops: improving their design without changing their function. That doesn't just apply to the design of code, but of data, configuration, hardware, service interfaces, and organizational communications and commercial channels.

In DevOps we extend this idea of Merciless Refactoring to proactively DRY the system of the organization until every responsibility for its behaviour appears once and only once. That minimizes the organization's cost of change. Doing so is essential in code to avoid generating exponential tech-debt - which is why Scrum proved unsustainable without XP:

The same math goes for DevOps. Without Merciless Refactoring, the systems that support first-way end to end flows grow ever more complex and thereby exponentially costly to maintain through changes required in response to 2nd-way feedback and 3rd-way experimentation.

Merciless Refactoring entails automation to simplify this process of simplification, reversing the ends of the First Way and assuring the organization is prepared to embrace change. So Development prioritises work on Operational metrics that assure Customer satisfaction and Operations prioritises work on costs of Development to accelerate Business throughput. This Way is the driver of DevOps' traditional, necessary and continuous investment in CI/CDD/BDD/RPA/SRE/B2D2 automation.

Enshrining Merciless Refactoring in the Zeroth Way reconciles Kim's DevOps with the natural functions of DevOps in automation and simplification. And it connects DevOps directly to the 9th Principle of the Agile Manifesto and the 9th Principle of Permaculture. It works as a refactoring of DevOps itself, improving its design without changing its function.