Together. We Create! Photo by "My Life Through A Lens" on Unsplash

Motivation

Recently I have accomplished a training of Agile Software Development. One thing I really like is the Agile Manifesto. It use four short but powerful paired terms to express the value it promote concisely. Each paired term consists of a left value and a right value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Manifesto for Agile Software Development

An idea just popped into my head: could I write a “DevOps Manifesto” in a similar way? That is, use paired terms to summarise the value DevOps promote.

I searched in Internet and found DevOps Manifesto by Jez Humble, a famous thought leader of the DevOps community. But the the subtitle of that page indicate it is still a note:

DevOps Manifesto

Notes on the open space session (no conclusions!)

(…)

DevOps Manifesto Page by Jez Humble

Indeed, it already extracted the core value of DevOps. I believe only a few modifications to the language are needed to create a short and powerful DevOps Manifesto.

So I come up with this, in the hope of throwing out a minnow to catch a whale. It could also considered as an answer to a million dollar question: what is DevOps?

If you have any comments or suggestions, consider raise an issue in the GitHub repo I have created for this: https://github.com/hughluo/A-DevOps-Manifesto

DevOps want to break silos between Dev and Ops. Let us break silos between thought leaders and participants!

A DevOps Manifesto

We are uncovering better ways of developing and operating software by doing it and helping others do it. Through this work we have come to value:

  • Cross-functional collaboration over organizational siloization
  • Neutral measurements over anecdote-driven decision
  • Gradual change over batched release
  • Speeding recovery over preventing accidents
  • Ruthless automation over comprehensive documentation

That is, while there is value in the items on the right, we value the items on the left more.

Origin

Cross-functional collaboration over organizational siloization

This paired value is directly from DevOps Manifesto from Jez Humble.

Neutral measurements over anecdote-driven decision

Measurement is also clearly a value should be in the manifesto.

I describe measurement with adjective “neutral”, inspired by Site Reliability Engineering from Google:

Our practice is then as follows:

(…)

The actual uptime is measured by a neutral third party: our monitoring system.

Site Reliability Engineering: Chapter 3- Embracing Risk

To find a proper right value is quite hard. I believe neutral measurements indicate data-driven decision making. So I searched “antonym data-driven” in Google and found this:

anecdote-driven

some organizations mindfully gather data and use it to make decisions. we often call these organizations “data-driven.” what about those that do not? what do we call them? if not with data, how do they make decisions? in my experience, they use anecdotes. managers make decisions based on discussions with or comments from 2–3 individuals. i call this “anecdote-driven,” and intend it as an antonym to “data-driven.”

Antonyms for data-driven at synonyms.com

I believe it is a good candidate for the right value. Since I don’t have other word in mind, I choose to use anecdote-driven decision as the right value.

Gradual change over batched release

The term “gradual change” comes from a subtitle in chapter How SRE Relates to DevOps in Site Reliability Engineering:

Change Should Be Gradual

The third key idea is that change is best when it is small and frequent.

(…)

— Site Reliability Engineering: Chapter 1- How SRE Relates to DevOps

Speeding recovery over preventing accidents

This comes directly from Site Reliability Engineering from Google:

(…) it is more profitable to focus on speeding recovery than preventing accidents.

— Site Reliability Engineering: Chapter 1- How SRE Relates to DevOps

Ruthless automation over comprehensive documentation

Automation should definitely has its place in the manifesto. Again, in DevOps Manifesto from Jez Humble I find a proper right value, documentation.

When I trying to find an adjective for automation, the name of a book Python for DevOps: Learn Ruthlessly Effective Automation come to my mind.

Reference

The Agile Manifesto, a short but powerful expression of the value of Agile, https://agilemanifesto.org/

DevOps Manifesto by Jez Humble, I burrowed almost all values there, https://sites.google.com/a/jezhumble.net/devops-manifesto/

Google SRE Books, another main source of paired values, https://sre.google/books/

DevOps Culture and Mindset, a course let me know more about DevOps, available in Coursera: https://www.coursera.org/learn/devops-culture-and-mindset

Agile Software Developer Nanodegree, a three month training I took for Agile, covering both theory and practice, available in Udacity: https://www.udacity.com/course/agile-software-development-nanodegree--nd144

Senior Software Engineer @ Instana, Programming / Human Language Enthusiast. Located in Munich, Germany

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store