Aurynn Shaw on Enabling a Sustainable DevOps Culture

Show notes

• 0:25 Introduction & background
• 2:40 Working with a render-farm supercomputer means deployment could not be in the hands of the individual programmer
• 2:52 The demand for automation when working at that scale
• 3:12 “Aurynn – you’re great, but have you heard about Puppet?”
• 3:28 Running and testing a program on the desktop is not running the program
• 4:10 The “why” of DevOps tooling – what is the business need.
• 4:21 This means you have to rethink the development approach based on the way it will be deployed
• 4:48 Different organisations have different needs and adopt DevOps in different ways
• 5:08 DevOps isn’t about the tooling – it is about the context in which we find ourselves
• 5:50 Conway’s law as a way of framing our organisations. We make artefacts that encode our organisation,
• 6:03 The inverse of Conway’s law tells us that adopting tools and artefacts will change our organisation
• 6:15 Microservices architecture as an example of this in action – microservices is a team-organisational structure not a technical architecture
• 6:25 Microservices only works if you can structure your teams to the level where they can take ownership of individual microservices with clearly defined interfaces
• 6:57 Examples of how this plays out in teams and organisations.
• 7:38 How implementing Docker impacts on team and organisation structures
• 7:58 These are technical ideas, but they impose cultural constraints
• 8:10 Sustainable DevOps is about understanding the system that makes up the organisation ecosystem and what needs to change to enable the new ways of working
• 8:19 This impacts way beyond just tech teams – it touches everything about how the organisation is structured
• 8:48 This means rethinking what deployments are, rethinking what constitutes a release, which means rethinking project management approaches
• 9:12 This means tracking back all the way to business goals and how they cascade down into the delivery of value for customers and the organisation as a whole
• 9:35 This is not about just implementing a technology – it’s a people change challenge
• 9:41 When deadlines loom people feel pressure, panic and drop new ways of working in favour of the familiar
• 10:28 A 30-minute solution for one person is likely to be a lot longer for someone else – context matters
• 10:52 Once we drop the new way of working under pressure, it’s done – it will be impossible to pick it up again
• 11:14 If you don’t have resourcing and permission for experimentation and failure, then you can’t do DevOps
• 11:44 Consider the downstream impacts of adopting DevOps on areas such as customer support
• 12:00 DevOps is about communication across the whole value stream – ensure the communication actually happens
• 12:35 Describing a typical engagement and common elements, and there is no one-size-fits-all model for DevOps implementation
• 13:33 Resourcing time for experimentation and failure into new project initiation and funding
• 14:01 Failure is inevitable – the things that we make will crash and burn in interesting new ways, how can we learn from those failures
• 14:32 The story of working with the people who control the change management process to enable more frequent deployment
• 15:44 The importance of viewing change from a non-judgemental viewpoint – not “good” or “bad”, just “is”
• 16:21 Change management is resistant to change because the business doesn’t want to visibly fail
• 16:42 Being resistant actually makes failure more likely and makes the failure more impactful and intense
• 17:09 There are processes to bypass change management, which makes the whole point of change management moot and meaningless
• 17:39 As technologists we don’t communicate the value of the new way of working very well
• 17:51 There have been decades f hostile behaviour and poor communication between technical and non-technical people.
• 18:12 These people have been treated badly by people like us, and they don’t trust us anymore
• 19:27 The first major step to take to build trust is to say “yes” rather than resisting change
• 20:04 “Yes, let’s find a way to do it”, not “yes, but no…”
• 20:48 Moving from a culture of blaming the individual to exploring what failed in the system that enabled something to go wrong, and focusing on fixing the system
• 21:08 The story of a high-profile, high-cost failure in an organisation
• 21:36 Distrust is created by saying “no” over and over again
• 21:48 The root cause analysis of the incident and walking back to an event six months previously, then correcting the mistake at that level
• 22:54 Design the system to help prevent dangerous actions rather than laying blame when something goes wrong
• 23:35 Describing the stack overflow problem and identifying what “done” actually means
• 24:26 If you don’t have a foundation of trust with a culture of “yes” then you DevOps will not solve any of your organisation problems
• 24:51 As a technologist you want to say “yes” – fix the systems around you that force you to say “no”
• 25:12 Find all of the places in the value stream which add pressure to say “no” and slowly modify them to allow the actions we do want, then modify them even further to prevent the actions we don’t want
• 25:25 This is a slow journey – it doesn’t happen overnight
• 26:08 In many organisations trust is a challenge, because the systems punish people and fear prevents trust from being established
• 26:12 The systems punish us for the behaviours they don’t want us to perform
• 26:17 The impact of this on the people in the organisation
• 27:46 The layered onion of systems within systems and how they impact each other to create dysfunctional environments populated by disengaged people
• 28:16 Good and bad only matter in the context of our outcomes
• 28:38 The root cause of contempt culture among technologists
• 28:58 The Linux Kernal mailing list as an example of contempt culture in action
• 29:44 When examining the system it is important to stress that there is no blame-game going on
• 30:08 When examining the system we will discover that we’ve done things that we’re not happy about and must accept that they happened without apportioning blame
• 30:25 This is hard because we are forced to consider the impact of our own behaviours and attitudes on others and on the system, and it’s uncomfortable
• 31:02 Asking oneself about the potential downstream effects of an action in a context

Mentioned

Eiara
Weta Digital
Puppet
Docker
Metcalf’s Law
Contempt culture
Linux Kernal mailing list
Aurynn on Twitter and personal blog