So given the problem of DevOps being somewhat vague on prescriptions at the moment, let’s look at some options.
One is to simply fit operations into an existing agile process used by the development team. I read a couple things lately about DevOps using XP (eXtreme Programming) – @mmarschall tweeted this example of someone doing that back in 2001, and recently I saw a great webcast by @LordCope on a large XP/DevOps implementation at a British government agency.
To a degree, that’s what we’ve done here – our shop doesn’t use XP or really even Scrum, more of a custom (sometimes loosely) defined agile process. We decided for ops we’ll use the same processes and tools – follow their iterations, Greenhopper for agile task management, same bug tracker (based off HP), same spec and testing formats and databases. Although we do have vestiges of our old “Systems Development Framework,” a more waterfally approach to collaboration and incorporation of systems/ops requirements into development projects. And should DevOps be tied to agile only, or should it also address what collaboration and automation are possible in a trad/waterfall shop? Or do we let those folks eat ITIL?
Others have made a blended process, often Scrum + Lean/kanban hybrids with the Lean/kanban part being brought in from the ops side and merged with more of a love for Scrum from the dev side. Though some folks say Scrum and kanban are more in opposition, others posit a combined “Scrumban.”
Or, there’s “create a brand new approach,” but that doesn’t seem like a happy approach to me.
What have people done that works? What should be one of the first proposed roadmaps for people who want to do DevOps but want more of something to follow than handwaving about hugs?
the agile admin 
It’s possible that devops isn’t a methodology or workflow, and therefore nothing to be prescribed. 🙂
But then what is it? If it’s just “vague unfocused advice” then I think we all have better things to do. But if we look at DevOps as anything someone can actually *do*, then obviously someone can benefit from guidance on how to do it.
Even just telling people “you should collaborate” and “you should communicate” is spitting in the wind. Who isn’t going to say “no shit, of course we should be doing that?” Everyone agrees with that. But then you’re faced with the hard reality that people aren’t doing it. Why not? Because they don’t know how to get there.
Even with ‘soft skills,’ the area where vague well wishing turns into execution has been with things like “How To Win Friends and Influence People” and “The Seven Habits of Highly Effective People”. We have a “Getting Things Done” (GTD) group meeting inside our company.
No matter what it is, if you convert it into specific methodologies, skill training, and/or roadmap, people can follow it to get there. If it’s just a list of things “you should do better,” with no prescription as to how, you will see no change – the experienced people that already know how to do it will sit secure and self-justified in the knowledge they are doing it, and the hoi polloi may admire from a distance but they won’t get there themselves.
“But then what is it? If it’s just “vague unfocused advice” then I think we all have better things to do.”
I understand the concern of not having something actionable and specific. But in my experience it’s just simply not prescriptive outside the context of the specific organization that you’re working in. Which means that you start with general philosophies that describe the specific bits in successful companies, and adjust to make it work. This is why it’s important for people who have found success bridging the stereotypical (and possibly plain-old caricature) dev and ops perspective
“Handwaving and hugs” isn’t something I’ve seen anyone advocate, and seems somewhat dismissive of the soft skills bits that I (and others) have reported as being successful. Also: hugging is cool.
It’s definitely not simply a vague list of things “you should do better”, for sure. If I read or heard something that was really that (empty advice, instead of on-the-ground reports of what has worked for someone) then I’d have the same view as you.
For example, I think that CAMS is something easily understood and actionable, when applied to your org: http://www.opscode.com/blog/2010/07/16/what-devops-means-to-me/. Not that it’s a checkoff list, but it’s a starting point for people to understand that devops isn’t a single One True™ tool/process/org or even culture to follow.
That’s where we start, but we have to get past that. I believe we can press quickly past ad hoc and into more methodology.
Visible Ops itself started with looking at specific company best practices, etc. But then they took it past that into a framework someone could actually implement. Sure, it needs customization for a specific shop, but what doesn’t?
Same thing with Agile. “Here’s some principles! Enjoy!” generates low uptake. Yes, the one in a hundred company who has someone visionary on staff that decides it’s a high priority can do it, but everyone else who is trying to get work done hears about this thing but it’s not clear what it is so never mind. Hence Scrum, XP, et al.
Soft skills are not soft headed, is my point. Soft skills are important. The successful paths to teaching people soft skills are, surprise, defined methodologies. So far the DevOps community is mostly stuck in saying the same damn high level thing over and over again, and then looking at each other with surprise when more people don’t jump on the bandwagon. CAMS is great but it is at the “very top level of the Agile Manifesto” level, and I think we need to, and can, push past that to more detailed principles and even methodologies. People need a strawman, a starting point. I’ve talked to Lord knows how many companies that have “heard of” DevOps, and are interested, but have absolutely no idea where to go from where they are (often they have implemented something DevOpsey, but aren’t sure it qualifies!). Telling them “transform your culture. Peace out!” is not very helpful. How many technical people know how to enact culture change? They need more detail than that. Right now we’re preaching something that is indeed understandable and compelling to all the high level architects with 20 years of operations experience. That’s a small frickin club and it should be obvious we need to put together more training wheels for the average shop to come play.
Sorry, there is dangling sentence in that last comment. I meant to finish with:
“This is why it’s important for people who have found success bridging the stereotypical (and possibly plain-old caricature) dev and ops perspective…to help the community and talk about what has worked (and not) for them, as a business”
I understand what you’re trying to get at now. I read ‘methodology’, and have an almost immediate aversion to a parallel of Agile (capital A), Scrum, XP, etc. void of details and specifics.
I agree that there should be more specific starting points for people to understand what the idea is about. And I’ll also agree that enacting culture change is just Fucking Hard™.
The folks who have had success in this area do indeed bear some responsibility in being specific on how this collaboration and communication scenario became successful. I’ll count myself in that population, so let’s see if I can’t be more specific over the next year. 🙂
Good to see the DevOps community growing and exploring new approaches to workflow. For those pursuing incremental evolutionary change, Kanban systems do play a part in a “service delivery” approach to improving services and customer satisfaction.
I invite you to join “kanbanOps” yahoo! group – recently created to provide a forum for DevOps & IT Operations folks to discuss Ops related issues.