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?