Why Culture eats DevOps for Breakfast
•Download as PPTX, PDF•
1 like•654 views
Based on customer engagements over the last 3 years this presentation explains the 6 stages most organisations work through as they attempt to move towards Continuous Development or Continuous Deployment. In this session we will explain the challenges and give you solutions that can help build your DevOps practice. Join the discussion to learn about common mistakes and how to avoid them.
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Why Culture eats DevOps for Breakfast
Similar to Why Culture eats DevOps for Breakfast (20)
More from DevOpsGroup
More from DevOpsGroup (20)
Recently uploaded
Recently uploaded (20)
Why Culture eats DevOps for Breakfast
- 2. 2
- 3. 3
- 4. 4 Edgar H. Schein. “Organizational Culture and Leadership" (1992) What is Culture? A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems
- 5. 5 Schein’s Framework Artifacts (Visible structure, Processes, Behavior) Espoused Values (Ideals, Goals, Aspirations) Underlying Assumptions (Values, Beliefs, Attitudes) Durabilityofchange Abilitytoinfluence Easy Difficult Short Long Organizational Culture and Leadership, Edgar H. Schein, 2010. http://amzn.to/2ox6Pxz
- 7. What is DevOps? Just to make sure we’re all on the same page!
- 8. 8 Why do we need a new model for IT? •Cloud Computing •Smartphones •Changing Demographics • And many, many more reasons* * But that’s a different presentation
- 9. 9 Organisations need to change John P. Kotter, “Accelerate!”, HBR The hierarchical structures and organizational processes we have used for decades to run and improve our enterprises are no longer up to the task of winning in this faster-moving world
- 10. 10 DevOpsGuys DevOps Defined #1 A set of patterns, practices and behaviours that are correlated with high-performing IT teams
- 11. 11
- 12. 12
- 14. 14 DevOps Delivers Success Source: Gene Kim Why Everyone Needs DevOps Now: My Fifteen Year Journey Studying High Performing IT Organizations Author, The Phoenix Project High performers leverage DevOps to drive competitive advantage. Speed More frequent deployments 200x Faster lead times than peers 2,555x Stability Higher success rates during deployments3x Faster fixes when things went wrong (mean time to recover (MTTR)24x Source: Puppet Labs 2013, 2014 State of DevOps Superior Market Performance More likely to exceed profitability, market share and productivity goals 2.5x Higher market capitalization growth over 3 years50%
- 15. 15 Organisational Success Factors Traditional Key Success Factor Modern Command & Control Management Style Autonomous Conservative Attitude to Change Experimental Silo Organisation Structure Collaborative Project-focussed Delivery Focus Product-centric Waterfall Delivery Model Iterative (Agile) Large (Huge) Batch size Smallest possible Monolithic Systems Architecture Loosely coupled Proprietary Technology Open (Source) Manual Processes Automated
- 16. Lessons from the field Some tips and tricks from theory & practice
- 17. 17 Know your Goal (aka Outcome) 1.2. 3. 4.
- 18. 18
- 19. 19 “You Can't Change Culture, But You Can Change Behaviour”. Damon Edwards, DevOpsDays, Rome 2012
- 20. 20 Schein’s Framework Artifacts (Visible structure, Processes, Behavior) Espoused Values (Ideals, Goals, Aspirations) Underlying Assumptions (Values, Beliefs, Attitudes) Durabilityofchange Abilitytoinfluence Easy Difficult Short Long Organizational Culture and Leadership, Edgar H. Schein, 2010. http://amzn.to/2ox6Pxz
- 21. 21
- 23. 23 Not everyone is in the same place! Pre-Contemplation Contemplation Planning Action Maintenance Finance PMO DBA’s “Shadow IT” DevOps Skunkworks Developer s OperationsInfoSec
- 24. 24 Decisional Balance Sheet Pro Con Keepdoing IT the way we currently do • It’s the easiest option • I don’t have tore-train • Businessis still complaining • Dev & Ops are still at war • Job satisfaction isn’t great • Risk of burn out is high • Our competitors will eat our lunch, again. Buy some Enterprise DevOps Automation tools • We can tell Management& the Business this is DevOps and get them off our backs • We might make some incremental improvements • Oooh, Shiny! • Vendor has great swag • We neverimplement Enterprise Suites properly anyway so the ROI is always poor • It’s very expensive • It will takes ages to implement • I’ll probably still hate my job Do a full DevOpsTransformation • DevOps benefits are well documented • We might stay in Business • I might enjoy my job again • Did I mention SHINY! • It’s a complex change • It will be personally uncomfortable • Will they make me redundant afterwards?
- 27. 27 Need to overcome inertia 2:1
- 28. 28 To Summarise 1. Understand your Goals (Where do you want to go?) 2. Identify your Constraints (What’s stopping you?) 3. Focus on encouraging the right behaviours (as behaviours change Culture) 4. Iterate towards your Goals (whilst tracking the right metrics) 5. Communicate constantly (with appropriate messaging) 6. Look for the Tipping Point (and use it when you see it!)
- 29. Thank You Any Questions? Email team@devopsguys.com Tweet @DevOpsGuys
Editor's Notes
- 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…….
- But we are starting to see the same kind of banal advice in the DevOps community – particularly around Culture.
- Patterns of shared basic assumption that the GROUP learned… to be taught to new members as the correct way to perceive, think and feel….
- 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.
- 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….
- 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.
- 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]
- 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.
- 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]
- 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]
- 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.
- 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]
- 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.
- Where you start across the DevOps pipeline is very dependent on the organisation Where is your constraint?
- 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
- 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!
- 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.
- Is 52% enough to trigger radical change? Yes if you’re Brexit, but for other things…
- The PROS need to outweigh the CONS 2:1 for people to move out of contemplation (at least for behaviour changes like weight loss).