It's the Ranger4 #DevOpsFriday5 series - today's contributor is Patrick Hyland.He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
DevOps and ITIL can be integrated to work together in a recursive manner. At the top level of recursion there is ITIL, an abstract map for the design of a service provider. It is a conceptual interconnected mental model, the 'cognitive niche' of a mature IT Service Management practitioner. It includes elements of strategy making, design, transition and operations within the abstract context of conceiving and realising services, whatever those services may be. I am not one to limit the scope of DevOps but one perspective is that DevOps is enabling territory, typically territory within the transition and operations areas of this map. So if we now go down a level of recursion within the transition and operations ITIL lifecycle subsystems it becomes apparent that the objectives of this part of the map can be realised by using DevOps practice and a Continuous Delivery value stream. For example, in the transition subsystem, the ITIL process areas of application development, service validation and testing, change management as well as release and deployment management are directly relevant to DevOps, ripe for automation and synthesizable with Continuous Delivery. Using DevOps here creates emergent properties that tend towards the sufficient requisite variety (Ashby) required to properly realise good transition and operations practice within a service provider.
Agile should float across both levels of recursion. At the lower level of recursion it can drive the development activity connected to the DevOps practice by using for example SCRUM and at a higher level I believe that ITIL subsystems and process areas can be linked up in an agile way using Kanban so that the service provider can then be managed using Goldratt's Theory of Constraints.0p
2) Can you describe what DevOps looks like when it’s ‘done’?
I dont think its useful to compare DevOps in an analogous way with Agile's definition of 'done'. My perspective is that DevOps is well described as creating a purposeful activity system (Checkland) and that system can then be monitored to see if it is operating in an efficacious, efficient and effective way.
So, lets define a system that DevOps creates.
DevOps creates a system to get developmental products and service feature inventory from engineering into the hands of the online customer by having available sufficiently skilled development, QA, operations and security staff who use an agile methodology and an automated continuous delivery subsystem to get reliable, tested, secure and operationally ready product or service into the hands of the customer as quickly as possible.
If this system is efficacious in transforming the developmental features to an operationally ready state, is able to get features to market fast enough to satisfy an established demand or to explore a new one and is able to get the company a competitive advantage in the market while reducing the wasteful use of skilled labour on repetitive tasks then the correct properties are emerging from the system that DevOps created.
3) What do you think are the key metrics for DevOps?In the first instance, I would only monitor a few key metrics.
1. The number of DevOps practicing teams doing SCRUM or Kanban (should be increasing)
2. Interruptions to the flow of work down the delivery value stream that can be directly attributable to siloed team interrelationships (should be reducing)
3. The acceptance criteria on operational and security requirements has quantifiable and executable test coverage (should be trackable and increasing)
4. Automation of the value stream steps in the pipeline (should be increasing)
5. The feature cycle time from continuous integration to production release (should be increasing)
6. Mean time to repair production incidents (stable at a low recovery time, or reducing)
4) What attributes constitute a culture embracing DevOps?
The ability to critically examine the boundary judgements that were used to put in place the current Architecture, Security, Development, Operations and IT Service management practices. Critical Systems Heuristics (Ulrich) is great for this especially to create a platform on which to start the collaborative discussions required to emancipate staff from siloed or otherwise poorly designed management systems.
A reflective organisation committed to ongoing learning (Senge).
Groups of people, Dev, Ops, ITIL people, Security, Architecture, Business People, all with different worldviews and/or perspectives but willing and able to try to understand each others points of view and then seek accommodations, if not consensus.
Strategy making within the context of DevOps becomes a collaborative activity that permeates through all the levels of the organisation.
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
DevOps practice tends to create systems out of which it becomes possible for Continuous Delivery to emerge. So Continuous Delivery becomes an emergent property of the system, an ability to be able to release operationally ready, reliable, secure and feature tested software at any time.
Continuous deployment is a setup where a release is not inhibited before it goes into production. Releases are automatically and constantly going into production. While this may be suitable for some applications, others with for example regulatory approval requirements may not be suitable for continuous deployment.
Continuous Service Improvement is a set of ITIL processes that draw on quality management theory such as Edwards Deming's iterative PDCA (plan do check act) improvement cycle. It can be used to plan improvements on the actual services or the interconnected service lifecycle that realises those services. Because it is possible for ITIL and DevOps to be integrated in a recursive manner, DevOps practitioners may want to read and understand CSI.
About Patrick: Patrick Hyland is a DevOps Engineering Management Consultant.
He is a co-founder of the OpsWorks Group, a London based DevOps Engineering consultancy and works with his business partners to create DevOps and IT Service Management strategy as well as managing the delivery of client projects.
Patrick has a total of 20 years of experience working with companies in the Development
and Operations space. He currently works as senior application engineering management
consultant managing resources across numerous service and product delivery projects.
Previously he was hands on in engineering roles at Betfair, The Economist, Lastminute.com,
Thawte (a Verisign subsidiary) and UUNET SA. Patrick holds an ITIL V3 Expert qualification
and a 3 year 'Financial Information Systems' tertiary Diploma.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.