Two things I hear often are:
(1) Why isn’t there a DevOps Manifesto like the Agile manifesto?
(2) Why isn’t there a “DevOps Framework” like ITIL or SAFe?
The DevOps manifesto issues has been discussed at length
“DevOps, a movement of people who care about developing and operating reliable, secure, high performance systems at scale, has always — intentionally — lacked a definition or manifesto” – http://www.thoughtworks.com/insights/blog/state-devops
Although there have been some attempts (http://theagileadmin.com/2010/10/15/a-devops-manifesto/) and openspaces sessions (https://sites.google.com/a/jezhumble.net/devops-manifesto/) on the topic but you can see from the comments that there is a “no manifesto” philosophy.
“Actually at the very first #devopsdays in Gent we agreed not to have a Manifesto .. the same discussion happened in Hamburg and again the end result was .. no manifesto …” (Kris Buytaert)
The “framework” question is more complex, however.
We’ve already seen maturity assessments (http://www.ranger4.com/devops-maturity-assessment/), maturity models (e.g. HP http://h30499.www3.hp.com/t5/Business-Service-Management-BAC/DevOps-and-OpsDev-How-Maturity-Model-Works/ba-p/6042901) and an implementation framework (e.g. IBM http://www.ibm.com/developerworks/library/d-adoption-paths/index.html?ca=dat-) that (rightly) stops short of actually being prescriptive on what DevOps “is”.
The problem with a comprehensive DevOps framework at this stage is (1) it sort of misses the whole point and (2) the challenges a 100% Cloud e-commerce website faces versus a large, heterogeneous, Enterprise and how to solve them will be very different.
When I say above that it “misses the point” I’m not trying to be flippant, elitist or trendy.
My view re DevOps is that it is about experimentation, learning, feedback, evidence-based & metrics-driven decision making etc etc all within the guidance of the CALMS model.
Just taking a prescriptive “blueprint” down off the shelf (from either a vendor or “standards” body) is almost a totally opposite mindset to the above (IMHO). If you’re not willing to experiment with different working methods, tools, org structures etc how will you find the one that works for YOUR organisation, at its stage of organisational development as opposed to a one-size-fits-all and often overly proscriptive “methodology”?
That said, I do believe that there is scope for guidance, best practices, case studies etc and hence why I am eagerly awaiting The DevOps Cookbook (http://www.realgenekim.me/devops-cookbook/) and Matt Skelton, Steve Smith et al “Build Quality In” (http://blog.matthewskelton.net/2014/06/01/experience-reports-book-on-continuous-delivery-and-devops-build-quality-in/).
Everyone needs guidance and help to get them started… and practitioner-led case studies that explain “we’re this type of company and we did these things to adopt DevOps and we had these positive and negative outcomes. Your mileage might vary” are IMHO the best way to do it.
If anyone is trying to sell you a “
10 step guaranteed lose weight in 30 days“, sorry I mean, “become DevOps-y in 30 days” plan then I would be taking it with a grain of salt at this stage of the DevOps maturity and hype cycle.
p.s. a version of this was originally published on LinkedIn here