DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog 5 Lessons learnt from the #DevOps enterprise summit EU 2016

5 Lessons learnt from the #DevOps enterprise summit EU 2016

This week London played host to its first ever DevOps Enterprise Summit, the Gene Kim led two day conference focussed on Enterprise DevOps adoption. There was a wide array of organisations represented by the speakers – from Financial Services (Barclays & ING) to Consumer Goods (Unilever) to Entertainment (Disney) to vendors like HPE and many others all talking about their own DevOps journeys.

So what were DevOpsGuys key lessons and takeaway messages from the event?

1 – No more excuses!

I think it’s fair to say that the wide range and scope of the Enterprises represented by the speakers destroyed the canard that Enterprise organisations can’t achieve a DevOps Transformation. They can, and they are, but it’s fair to say that it’s not easy nor for the faint of heart.

The Barclays case study in particular outlined the challenges of adopting DevOps across a 15,000+ employee global IT organisation. Other excuses like “you can’t do DevOps in regulated environments because of PCI | SOX | ” was also directly addressed by some of the speakers – you can, they are, you just need to engage with the auditors directly early & often.

2 – “One size does not fit all” for your approach to DevOps Transformation

One phrase that was repeated over and over again (for two reasons as we will explore below) was “One size does not fit all”.

Many of the speakers made the point that their organisations’ approach to their DevOps Transformation was bespoke to them – it depended on their goals, their constraints, their systems, their culture etc etc.

Blindly adopting “what Google do” or “what Etsy do” is a recipe for disaster. We (DevOpsGuys) know this from our own work with our clients. We start with a Discovery phase to ensure that we understand their context and then collaborate with them to create a plan that works for them. Each one is different. One size does not fit all.

3 – “One size does not fit all” inside your DevOps model

The second way that “One size does not fit all” is inside your DevOps model itself. Teams need to have the autonomy to achieve their purpose without being smothered under the weight of overly restrictive, centralised, globally enforced “standards”. Start with Why, focus on the outcomes, and leave the “what” up to the product team itself.

That said, a technological and methodological free-for-all can create a support nightmare, reduce mobility between teams and impede collaboration. Which is why some organisations are looking to the open source software (OSS) movement to adopt “inner source” (or iOSS if you prefer).

The goal here is to create easily accessible, re-usable code that developers can use to accelerate their own delivery (application code, infrastructure code, test frameworks etc etc). Create libraries, patterns and practices that people WANT to use, can contribute to and constantly improve, rather than centrally imposed, static and dogmatic “Enterprise Frameworks”.

4 – “Top Down and Bottom Up”

People don’t want DevOps done TO them, they want DevOps done WITH them.

Another contender for “Catchphrase of the Summit” was “Top Down and Bottom Up”. The context for this is that your DevOps Transformation needs support from both the top (the C-Suite) and the bottom (the IT staff at the coal face) if it is going to succeed.

Grass roots DevOps initiatives (often focussed on technical goals like ELK, Docker and “infrastructure as code”) falter when they try to move outside their silos (e.g. Devs trying to get Ops involved or vice versa). They don’t have the mandate or political “juice” to change how other teams work. Collaboration is strangled at birth and DevOps fails.

Similarly a purely “Top down” DevOps transformation driven from the C-Suite can feel like “just another fad”, particular to jaded Enterprise IT Pro’s who have been through numerous other imposed frameworks in the past. The Enterprise immune system is triggered, resistance grows, and change fails.

Multiple speakers made the point that the C-Suite needs to show real leadership and be actively involved in the DevOps Transformation, removing obstacles, devolving autonomy and constantly seeking (and listening to) the feedback from their teams.

People don’t want DevOps done TO them, they want DevOps done WITH them.

5 – Holistic approach to DevOps is crucial

Another recurring theme is that your DevOps model needs to be holistic (which aligns neatly with the “First Way of DevOps”).

There was a running joke that DevOps needs to be renamed BizMarketingHRFinanceProductDevSecOps or something like that to truly encompass all the teams that need to be involved in moving to a DevOps model.

Systems thinking and the Theory of Constraints are inherent in DevOps – they are part of the philosophical framework that underpins DevOps – so it’s no real surprise that we have to consider the WHOLE system that is involved in moving from “concept to cash” to identify the real constraints and follow the POOGI cycle to ensure that things improve.

So that’s our top 5 take aways from DOES EU 2016. We will do a longer write up of the event itself later but we are already looking forward to DOES EU 2017 in June 2017!

Leave a Reply

Your email address will not be published. Required fields are marked *