Yesterday I travelled all the way to the dev/winter/ conference in Cambridge (UK) to speak about database CD and learn what I could from the other (more talented) speakers. Great sessions, friendly vibe, great food (and beer)… free. Highly recommended if you are in the area. 🙂

One of my favourite sessions was by Alex Wilson of Unruly (b|t). He asked the question: “What can DevOps learn from Extreme Programming (XP)?”

XP, compared to DevOps, is a relatively mature/old development methodology which promotes taking beneficial practices (such as code reviews) to the extreme (for example, pair programming, where code is continuously being reviewed) and Alex discussed how it has been successfully rolled out at Unruly.

Alex proposed that one of the reasons for the success of XP at Unruly is based on its core set of values:

• Simplicity
• Feedback
• Courage
• Respect
• Rules

One of the problems with DevOps, he suggests, is the lack of values at the foundation:

“One of the great things about DevOps is all the cool tools you can use to do your job!”

Anonymous

Case in point.

(SPOILER ALERT: This paragraph and the next discuss the plot of The Phoenix Project.) Alex suggested an unusual take on The Phoenix Project. (Sidenote: for a minute when looking for that link I thought they were turning it into a film! But I don’t remember any necromancers at Parts Unlimited?) For those that haven’t read it it’s “a novel about IT, DevOps and helping your business win” and some would argue it has become the DevOps Bible. But is it?

According to Alex it isn’t about DevOps at all. The pivotal moment in the book is where the main characters sit around in a boardroom and pour their hearts out. The positive “DevOps” collaboration happens, not as a result of “doing DevOps”, but because the people found a new respect for each other. This book is about XP.

Alex asked what the values were that guided DevOps, because it shouldn’t be just processes and tools. He gave examples of agile consultants who come into an organisation and set up a bunch of new processes – but if the people at the company are just following the rules, without any understanding of the values behind them what is the point?

So this got me thinking, what are the underlying values of DevOps?

Could it be the three ways? I don’t think so. Systems thinking? Feedback loops? Continual Experimentation? They sound like processes to me. These are the things we do, not the reasons we do them.

Could it be CALMS? (Culture, Automation, Lean, Measurement, Sharing.) That doesn’t really do it for me either. Closer – but is “Culture” specific enough? It needs to be qualified. Every organisation has a culture, what is the difference between a good and a bad one. Also, please don’t try to quantify culture.

 

Also, “Automation”? I’ve said before that I don’t think that terminology is clear enough. What does “Automation” mean? Automating a process and automating a trigger are two very different things. Also, is “Automation” a process or a value? I understand that DevOps wants it to be a cultural value, but that strikes me as a little dangerous. Often DevOps faces criticism for worrying to much about the process of automation, rather than the reason behind it. “Lean”? Well now we’re just stealing libraries from other enormous methodologies.

I think Alex has a point.

If I was to imagine my own simple, digestible list of values I would probably start with stuff like:

• Collaboration across business silos
• Respect for all colleagues (in dev, ops or elsewhere in the business)
• Shared goals to keep everyone pulling in the same direction

But here’s the problem. This is just my opinion. The DevOps community has not called these out. Therefore, while I love DevOps and regularly preach about it, I believe Alex is right and I would like to see the DevOps community collectively decide what to call out.

But perhaps this raises a larger concern. Shouldn’t we have sorted these out first? Are we retro-fitting core values into a legacy methodology? I don’t think we are. I believe there are some core values that DevOps people have always shared – I just don’t think we’ve done a very good job of articulating them yet.