It's the Ranger4 #DevOpsFriday5 series - today's contributor is Eric Minick. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
The Agile Manifesto is in many ways the DevOps Manifesto. You just go back and reread it thinking about production. To the degree Agile failed, it was in its inability to escape the development team and become a change to how IT and the business works. DevOps builds on what went well with Agile, and extends much of that into the Ops side of the house. Which brings us to ITIL. Done badly, ITIL is a ticket ridden hellscape of process overhead. Implemented well, it aligns very nicely with DevOps. Look at the Visible Ops Handbook as a good example.
2) Can you describe what DevOps looks like when it’s ‘done’?
This is similar to asking what Lean Manufacturing looks like when its "done". There's a lot of collaboration. The delivery systems are optimized to handle changing needs. Batch sizes for things tend to be small. At the same time, things are changing. We are building learning organizations and they will regularly be changing their own processes, tools, etc to get better.
3) What do you think are the key metrics for DevOps?
- Time in delivery pipeline: Mean time from code commit to in production, used by real customers. A similar measurement is the null release cycle time.
- MTTR: Mean time to recovery implies a great deal about your monitoring/diagnosing tools, speed of fix delivery, and infrastructure automation. Fast
- MTTR gives the business a safety net to make more changes, and resiliency to infrastructure issues.
- Bottom line: A focus on the core business metrics of the app (eg: profit per time/user in the case of e-commerce) is central to effective DevOps. The definition of success isn't an IT centric metric, as much as making sure we are helping the business win.
4) What attributes constitute a culture embracing DevOps?
Answer I think you see an embrace of experimentation coupled with responsibility. We want to try stuff and learn quickly, without being overly destructive. So you see disciplined, cross-functional teams. You don't hear, "That's not my problem"
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
I really think DevOps is first and foremost about helping the business win. Does Continuous Delivery do that? Very often it does, and so it ends up being something teams adopting DevOps will shoot for. To achieve continuous delivery you need to continuously do a bunch of other things - shuffle the backlog so the most valuable work gets done next; build new code changes; deploy them to test labs; test them; release the changes; monitor to learn from production. All of these practices support one another, help the team avoid waste and delivery more continuously.
About Eric: Eric Minick is a DevOps Evangelist who joined IBM through its recent acquisition UrbanCode. Eric has spent the last ten years helping organizations large and small adopt continuous integration, delivery and now DevOps. He is a frequent speaker on the topic, and writes frequently on continuous delivery topics. Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.