It's the Ranger4 #DevOpsFriday5 series - today's contributor is Simon Parkes. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
I think it’s a delicate balancing act. Agile and DevOps obviously go hand in hand. Agile practices drive organisations to deliver faster, which then exposes those long handoff processes to Ops that can often be the enemy of faster delivery. To me DevOps is the natural extension of Agile concepts, which help to eliminate those handoffs and encourage collaboration.
By contrast, ITIL is viewed as a blocker to fast delivery, and therefore the enemy of Agile and DevOps. However, in my experience, it is not ITIL itself which is the issue, but instead the implementation of ITIL which can create those blockers. Rather than use ITIL as a framework to create the required level of control, organisations tend towards creating complex change control processes, based on a very ITIL-based organisational structure, with clear lines of demarcation between responsibilities.
I don’t believe anyone would argue that Agile delivery means there is no need for change control. We use change control to provide assurance that the release is ready for release to production, and that we have the right mechanisms in place to be able to support that release. Even a highly Agile, continuous deployment organisation will use some form of change control to ensure that at all times production remains stable. I believe there is a place for ITIL-based process and control in a DevOps organisation, but it needs to be a light touch which provides “Just Enough” control, so that organisations can realise the true benefits of DevOps.
2) Can you describe what DevOps looks like when it’s ‘done’?
I think “done” will always depend on what problems you were trying to solve with DevOps in the first place. The driver behind the DevOps transformation here at Ordnance Survey was to reduce the amount of Work In Progress, by breaking down our historic working silos, removing the traditional handover processes, and encouraging greater collaboration as a means to generate faster software delivery. Therefore, for us “done” would be a place where members of development and operations form high functioning teams for the duration of a project, where the team come together as whole to work on stories, and where ops requirements such as NFRs (Non-Functional Requirements), security, etc are given equal priority in a common backlog to functional requirements.
In the course of our DevOps journey, we have found that automation, particularly of our infrastructure, has played a crucial role in achieving fast delivery, so there is an argument to say that another version of “done” would be to have an integrated, automated infrastructure delivery pipeline which provides a mechanism for rapid delivery of dev infrastructure requirements. If you can put in place automation that makes deployments boring, with no risk, then you could say that you have achieved a level of “done” for DevOps automation.
However, for me the essence of DevOps is a world of collaboration and shared concerns in any project or product. You can argue that continuous improvement, innovation and an ever changing technology landscape will mean that you could never truly say “we have done DevOps”, but if we can create a working environment where dev and ops are collaborating as single project teams, then I would say we have reached a stage of “good enough”!
3) What do you think are the key metrics for DevOps?
A lot of people talk about deployment frequency, deployment success and failure rates, and recovery time, as being the key metrics as these can point to how good you are at updating your systems and infrastructure. But I think these are all different ways of describing how good you are at dealing with the output of the projects. The key metric for me would one that deals with a holistic view of the project lifecycle – i.e. how long something takes to go from idea to deployment. This would provide a complete picture of how efficient your pipeline is, and therefore how effective you are at getting your product out to market. You can break this down into individual work packages, and put metrics around each of those, but a metric which covers the whole view would be the key to telling you how good you are at delivering value.
4) What attributes constitute a culture embracing DevOps?
- Embracing change, or at the very least not fearing change
- Trust, where Dev and Ops trust each other and stop referring to each other as “that lot”
- Communication, to break down the silos
- Collaboration, to create strong working relationships
- A sense of ownership over what is being delivered – ownership, accountability and urgency are all key qualities that ensure work in progress is minimised and delivery is maximised
- A clear vision of what you are trying to achieve and why. This will ensure you remain focussed on implementing your version of “done” for DevOps to resolve your problems. Otherwise you could implement something that looks like DevOps, but your bottlenecks and struggles may still exist.
- Support and trust of Senior Management. This ties in with the point made above. If the management team understand what you are trying to achieve, and why, then they will be better placed to support your endeavours and help you put in place what you need
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
I think it’s fairer to say that Continuous Delivery could be an output of DevOps, rather than the goal itself. It comes back to my point about knowing what you are trying to achieve with DevOps, and why. You can achieve Continuous Delivery with DevOps, but equally with the right structure and process you could achieve the same goal without DevOps.
All of the “Continuouses” can play a part in achieving DevOps – Continuous Integration and Testing will lead to faster development cycles, Continuous Deployment and Delivery will enable faster feedback cycles, rapid time to market, and will therefore all contribute to a reduction of WIP. But none of them are the goal of DevOps, and none of them are necessarily crucial to DevOps.
To me, the one area that should be an integral part of DevOps is Continuous Improvement. We should always be asking “what can we do better?”. This will force us to make sure our delivery pipeline, whether it is people, process, culture or technology, is always the most efficient it can be, which in turn will speed up our time to market.
Simon is an Enterprise Architect and DevOps Consultant at Ordnance Survey. Simon is driven by helping organisations maximise their delivery potential by focussing on improving their delivery pipeline. He is driving the DevOps transformation at Ordnance Survey, where he spends his time working with projects across Ordnance Survey, helping them organise themselves to deliver quickly, successfully and sustainably.
When not extolling the virtues of DevOps, Simon is responsible for defining the technology strategy and roadmap for Ordnance Survey, with a view to using technology and tooling to underpin the DevOps culture.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.