The question is Are you really doing DevOps?
As we pointed out in our earlier DevOpsDays wrap-up blog there are at least 7 different definitions of what DevOps is, judging by the presentations given on the day:
DevOps … is a movement, a philosophy, a way of thinking.
DevOps … is a person who can perform both Dev and Ops roles.
DevOps … means cross skilling people.
DevOps … is continuous delivery.
DevOps … is a team of developers and operation staff.
DevOps …is a culture movement.
DevOps … is monitoring.
So… what’s the “minimum viable product” (MVP) for DevOps? What core things shouldyou be doing before you can truly say you are “doing DevOps”?
In the whitepaper “The Top 11 Things You Need To Know About DevOps” Gene Kim emphasizes the “3 Ways”:
(1) “ Emphasize the performance of the entire system” – a holistic viewpoint from requirements all the way through to Operations
(2) “Creating feedback loops” – to ensure that corrections can continually be made. A TQM philosophy, basically.
(3) “Creating a culture that fosters continual experimentation and understanding that repetition and practice are the pre-requisites to mastery”
These are excellent guidelines at a high level, but we’d like to see a more operational definition. So we’ve made up our own list!

As a starter – we propose that;
1. You must have identified executive sponsors / stake holders who you are actively working with to promote the DevOps approach.
2. You must have developed a clear understanding of your organisation’s “value chain” and how value is created (or destroyed) along that chain.
3. You must have organizationally re-structured your development and operations teams to create an integrated team – otherwise you’re still in Silos.
4. You must have changed your team incentives (e.g. bonus incentives) to reinforce that re-alignment – without shared Goals you’re still in Silos.
5. You must be seeking repeatable standardized processes for all key activities along the value chain (the “pre-requisite to mastery”)
6. You must be leveraging automation where possible – including continuous integration, automated deployments and “infrastructure as code”
7. You must be adopting robust processes to measure key metrics – PuppetLab’s report focuses on improvement in 4 key metrics – Change Frequency, Change Lead Time, Change Failure Rate and MTTR. We suggest Availability, Performance and MTBF should be in there too.
8. You must have identified As mentioned above, this is just a starter list – feel free to agree/disagree in the
comments and suggest additions or alterations.