Why Culture eats DevOps for Breakfast

Editor's Notes

• #3: This is me back in 1999 when I first really became interested in national culture and organisational culture… I had moved from Australia (working as a contractor to the public sector in the Australian Capital Canberra) to working for a French investment bank (Banque Paribas) based in London. Suffice to say it was a bit of a culture shock… My favourite example from that period – the first is my first August working for a French company… so my boss Ivan goes on holidays, and his boss goes on holiday, and HIS boss goes on Holidays… all at the same time. I’m like WTF? I’d never seen that in 10 years working in IT in Australia (even in the public sector). I think it’s fair to say it says a lot about an organisations culture if 3 layers of management are comfortable all going on holidays simultaneously…. Exactly WHAT it says I leave as an exercise for you the audience. FAST FORWARD 18 YEARS AND now culture is on everyone’s lips…….
• #4: But we are starting to see the same kind of banal advice in the DevOps community – particularly around Culture.
• #5: Patterns of shared basic assumption that the GROUP learned… to be taught to new members as the correct way to perceive, think and feel….
• #6: Artifacts – the stuff you would see, hear, and feel when you encounter a new group; tech, products, clothing, ceremonies, etc Values - ultimately reflects someone ’ s original beliefs and values (founder or strong early leaders) become transformed into nondiscussible assumptions as the group learns to trust them Underlying assumptions – things we take for granted When a solution to a problem works repeatedly, it comes to be taken for granted. What was once a hypothesis, supported only by a hunch or a value, gradually comes to be treated as a reality.
• #7: Note that Culture is the “hidden part of the iceberg”… The key to remember is that YOU are part of the Culture – you don’t exist outside it. So when you complain about our organisations culture maybe you should start by looking at your own behaviour first….
• #9: Before we dive into WHAT Devops is, and isn’t, it’s worth asking the question “Why do we need a new operating model for IT”? There are many factors as play but I’d like to highlight 3 factors that have a major influence on the need for change The first is Cloud Computing – cloud computing has fundamentally changed the underlying economics of computing. New entrants – digital native startups – no longer need to build their own data centres, buy servers, storage and networking in order to get started. They can use per minute billed, global scale IaaS, SaaS and PaaS services and scale their usage to meet customer demand The second is the rise of the Smartphone – “we’ve got an app for that” is now a ubiquitous expectation across almost all consumer and B2B sectors. This has put enormous pressure on IT to ship new features, and new back-end integrations services - (API’s) - into their often aging legacy software estates Thirdly is the changing demographics of “digital natives” and “millennials” who have grown up in a internet-enabled, smartphone-centric world. They expect “on demand” services, on their phones and laptops, with a seamless customer experience between the two, and ideally that seamless experience extending into the physical world, for example for bricks&mortar retailers. All of this combines into a wave of Digital Disruption & Innovation that needs new, faster and better ways of deliverying IT services.
• #10: John P Kotter – Harvard Emeritus professor and leading management theorist for 30 years – but it best when he said [quote] In turn, this lead IT practitioners and researchers to look at what the leading tech (and often digital native) IT companies were doing – the Googles, Amazons and Netflixes of the world. Which leads to the simplest definition of DevOps – [click]
• #11: What they found was that they high performing IT organisations were able to achieve the best of both works – class leading “SPEED” and “STABILITY” – the fast flow of features into product AND high availability and resiliency.
• #12: What they found was that high performing IT organisations were different in 5 key areas… Culture – they embraced change, were more autonomous and more empowered Automation – they were leveraging the latest automation tools like Puppet, Chef and Ansible Lean IT – they were embracing Lean IT principles borrowed from manufacturing (particularly automotive and the Toyota Production System e.g. Kanban) but more importantly focussing on small batch sizes and the flow of work through the system Measurement – they were using advanced measurement techniques to provide constant feedback on their customer needs, and the impact of their IT initiatives. Less opinion, more data science! Sharing – a focus on breaking down silos between departments and sharing knowledge and best practice, often using ideas drawn from open source software development. Let’s quickly drill down into 2 of those in a bit more detail – breaking down the silos and the flow of work… [click]
• #13: most traditional IT organisation are organised by TECHNICAL ROLE into a series of silos – each with a different waiting queue, with a different SLA, each focussing on optimising it’s own part of the end to end value stream. Think of it like a car engine – if your carburettor or fuel injection system only focussed on “its role” and tried to “maximise its utilisation” it would pour the maximum amount of fuel and air it can up to the limit of its designed capacity into the cylinder, regardless of the current throttle input or engine revs. End result – the engine stalls and dies. The system breaks. DevOps is systems thinking – let’s look at the OUTCOME we’re trying to achieve, and design a model optimise for the fast flow of work, normally with smaller batch sizes, and organised around multi-disciplinary teams. SO what does a product-aligned, multi-disciplinary DevOps team look like? [click]
• #14: The idea of a DevOps product delivery team is that they own a defined product from initial design and development right through into production deployment AND operations – Dev & Ops together in a vertically integrated team. The product owner is empowered to prioritise the backlog of work, based on the organisational goals, customer needs and the fast feedback of data from customers and product (remember the M for measurement in CALMS). The goal here is to balance out the “user stories” (new features) with the “Operability stories” (things that make it easier to manage, reduce outages or cloud hosting costs etc). All of this underpinned by a focus on automating as much as possible, to free up time for higher value work.
• #15: The performance difference between high and low performers across 4 key metrics that measure Speed & Stability is stark. And this flows through into higher organisational performance. But this isn’t any easy journey – it is a challenging organisational transformation that is normally part of a wider Digital Transformation [click]
• #18: To complete the Metrics Framework, follow 4 simple steps: Identify your outcome. Determine what you can do to impact that outcome (levers). Determine how you know you have changed the right things. Determine how you know you have made progress towards the outcome.
• #19: Where you start across the DevOps pipeline is very dependent on the organisation Where is your constraint?
• #21: When a solution to a problem works repeatedly, it comes to be taken for granted. What was once a hypothesis, supported only by a hunch or a value, gradually comes to be treated as a reality. NEXT SLIDE - ITERATE ITERATE ITERATE
• #23: Communicate / Communicate / Communicate We use Agile Surgery – a weekly drop in. Plus lots of VISIBLE Work in Progress Do whatever you can to make what you do VISIBLE / TRANSPARENT and INTERESTING. But not just “cool” or “trendy” – make a difference in people’s daily lives!
• #24: Who is at what stage will depend on your organisation and where you are on your journey but the key point is NOT EVERYONE IS IN THE SAME PLACE AT THE SAME TIME.
• #27: Is 52% enough to trigger radical change? Yes if you’re Brexit, but for other things…
• #28: The PROS need to outweigh the CONS 2:1 for people to move out of contemplation (at least for behaviour changes like weight loss).