It's the Ranger4 #DevOpsFriday5 series - today we will hear from Daniel Breston. Take it away Daniel!
1) How would you describe the relationship between DevOps, Agile and ITIL?
They all do similar things: get people, supplier partners, processes and technology to create, deliver, support and improve a business process or need via the use of something technical. DevOps and ITIL are very closely aligned but DevOps has a focus on automation. Agile and ITIL meanwhile look at the software side so what are we trying to create then the integration of people into teams to quickly deliver a tested product or feature ready for use and support.
2) Can you describe what DevOps looks like when it’s ‘done’?
It is never done! Never! Ever!
Most people fail in DevOps, Agile, ITSM or whatever movement you want to consider by having the word DONE. Done removes the concept of improvement and improvement is the heart and soul of technology. If we had no improvement then the stuff created 60 years would still be what we use today. We need to continue the integration, collaboration, communication of the use of technology to enhance the way people work and customers benefit.
3) What do you think are the key metrics for DevOps?Indicators of Performance that are Key for me will be those that show we have attained the required on Quality, Productivity, Safety, Cost and Resource use and Training. These measures must be understood by ALL that are impacted such that daily they can determine their contribution, spot problems and begin to resolve them or suggest improvements.
4) What attributes constitute a culture embracing DevOps?
Culture is not DevOps. Culture is a big word and it is the way the people in an organisation allow for the use of technology to create great things for the use by customers. I prefer the word climate when applied to DevOps as mentioned by Stephen Parry. In IT we can begin to change the climate of people interfacing and then using automation without fear of job loss. This climate then begins to permeate the whole spectrum of an organisation and hopefully becomes its culture.
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
People get hung up on this word Continuous. Why does something need to be continuous? What does it mean in our environment or business? Do we need to go to a 7 second release cycle? Do we need to go to a 7 second deploy (usage) cycle? Or instead, can we set aggressive targets and use these to continuously improve how we work? I prefer the approach of using the capabilities implied by continuous to drive improvement. I am happy for an organisation to then say we continuously deploy (creation thru delivery) every month.
About Daniel: IT Service, Applications, Operations, Supplier management professional of over 30 years with the last 10 as a consultant, coach and speaker. I am All Things ITSM and Business Continuity and lean and DevOps practitioner for leaders and managers.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.