DevOps has been a great success in that all the core people that are engaged with the problem really ‘get’ it and are mainly on the same page (it’s culture shift towards agile collaboration between Ops and Dev), and have gotten the word out pretty well.
But there’s one main problem that I’ve come to understand recently – it’s still too high level for the average person to really get into.
At the last Austin Cloud User Group meeting, Chris Hilton from Thoughtworks delivered a good presentation on DevOps. Afterwards I polled the room – “Who has heard about DevOps before today?” 80% of the 30-40 people there raised their hands. “Nice!” I thought. “OK, how many of you are practicing DevOps?” No hands went up – in fact, even the people I brought with me from our clearly DevOps team at NI were hesitant.
Why is that? Well, in discussing with the group, they all see the value of DevOps, and kinda get it. They’re not against DevOps, and they want to get there. But they’re not sure *how* to do it because of how vague it is. When am I doing it? If I go have lunch with my sysadmin, am I suddenly DevOps? The problem is, IMO, that we need to push past the top level definition and get to some specific methodologies people can hang their hats on.
Agile development had this same problem. And you can tell by the early complaints about agile when it was just in the manifesto stage. “Well that’s just doing what we’ve always done, if you’re doing it right!”
But agile dev pressed past that quickly. They put out their twelve principles, which served as some marching orders for people to actually implement. Then, they developed more specific methodologies like Scrum that gave people a more comprehensive plan as to what to do to be agile. Yes, the success of those depends on buyin at that larger, conceptual, culture level – but just making culture statements is simply projecting wishful thinking.
To get DevOps to spread past the people that have enough experience that they instinctively “get it,” to move it from the architects to the line workers, we need more prescription. Starting with a twelve principles kind of thing and moving into specific methodologies. Yes yes, “people over process over tools” – but managers have been telling people “you should collaborate more!” for twenty years. What is needed is guidance on how to get there.
Agile itself has gotten sufficient definition that if you ask a crowd of developers if they are doing agile, they know if they are or not (or if they’re doing it kinda half-assed and so do the slow half-raise of the hand). We need to get DevOps to that same place. I find very few people (and even fewer who are at all informed) that disagree with the goals or results of DevOps – it’s more about confusion about what it is and how someone gets there that causes Joe Dev or Joe Operator to fret. Aimlessness begets inertia.
You can’t say “we need culture change” and then just kick back and keep saying it and expect people to change their culture. That’s not the way the world works. You need specific prescriptive steps. 90% of people are followers, and they’ll do DevOps as happily as they’ve done agile, but they need a map to follow to get there.
the agile admin 
I very much enjoyed the posts about DevOps “state of the Union”. Two things.
First, I find it … curious? that there seems to be a great mystery as to how to run technical organizations in general. I am not speaking from a wealth of experience leading technical organizations, but as “fresh eyes” in the technology sector. The necessity of DevOps strikes me as almost inevitable. For some reason it appears that the assembly line analogy stuck and it takes a great deal of effort to switch paradigms. We struggle to find examples, prescriptive steps, etc, yet we have plenty around us where this has already been figured out. Take, for example, a military special forces team. All very professional, with a degree of specialization, cross-trained, and able to work together to perform the most difficult tasks asked of a human being. And the process has been figured out for quite a while now, with much higher stakes – life (which is probably why the process is more advanced, because everyone is focused on the goal). This DevOps process does not need to be a mystery if we are willing to see patterns in the world around us.
Second. Lean seems to be painfully absent from the few DevOps articles I’ve been able to take a look at this afternoon. What is the benefit of bringing Agile to Operations without knowing why should the whole thing be more efficient in the first place? And I’m not talking about the assembly-line six sigma stuff. I’m talking about Lean Product Development of Donald G. Reinertsen variety. Taking that and applying it to business will drive DevOps as a result, with a purpose, with a reason, and with a measure to optimize/target for. Agile in Operations still does not answer the question of why. Without the why, what is the metric for success?
I agree that there are loads of useful metaphors – military and sports are two good ones – that could be plumbed for analogous operations. But inertia applies everywhere; it takes the Army quite a while to get their act updated from war to war too; often it takes decades. Technical stovepipes worked great in the mainframe age. Mainframe to client/server to Web paradigms have been traversed a lot more quickly than Korea to Vietnam to Afghanistan, to stretch the analogy.
And yeah, some folks talking more about Lean would be nice. I don’t know much about it myself, but from what I’ve read perhaps a “Scrum+Lean combo” could be one of the early DevOps variant prescriptions.
Pingback: Specific DevOps Methodologies? « the agile admin