DevOps is commonly recognised to be primarily about creating a culture of effective and seamless collaboration but this is often the hardest piece to enact when it involves changing an existing culture (as opposed to creating a culture from scratch in a startup type environment and having the luxury of hiring individuals with certain mindsets and defining working practices from day one). So how can you change culture? Here are our top ten tips:
1. Learn to Trust
It sounds a little cheesy I know, but at the core of what DevOps is trying to fix is the conflict that has come about from years, decades even, of development and operations teams being segregated from one another and not being enabled to communicate, let alone collaborate, effectively. This situation has been exarcebated by the pressures to innovate and push rapid change battling with the need to stabilise fragile systems – and created what James Turnbull described as a ‘toxic’ working environment.
So the very first thing that needs to happen is a unified agreement and understanding that we are all on the same team.
DevOpstastic Tip ~=>
Take some time to review your individual and team goals and ensure none are in conflict. Then create a single goal that brings everyone together. Get everyone to agree it. Fire anyone that can’t. Kind of joking – but kind of not.
A change in culture will demand changes in the way that you do your daily work – habits will need to be broken.
DevOpstastic Tip ~=>
Shift left – arrange your teams around projects not linear tasks and involve operations staff who will be responsible for your application in production much earlier in the process. Being involved sooner will help them plan for when the code is ready and feel they also have some skin in the game.
2. Understand Motivations
Conflict often occurs when people don’t understand each other – I’m sure we’ve heard the phrase: “They have a personality clash” countless times over the years. Humans and our brains, personalities, backgrounds and characters come in a whole heap of flavours and this is a good thing since, as my mother always says: “It would be boring if we were all the same.” However, sometimes at work, under pressure, it’s difficult to take the time to understand why someone is reacting or thinking differently to you and the immediate response is to fight or denounce it; not just unpleasant but downright unhealthy.
So if we accept we are all on the same team, how can we all get to know each other better and grease the wheels of collaboration? I know I’ve been subjected to countless team-bonding exercises that I’ve found quite excruciating over the years so I am applauding the new wave of neuroscience that allows us to be a little more exact about what’s going on in our heads than just try and decide whether I am a green or red personality type.
Our particular favourite at the moment is SCARF from The Brain at Work – the premise is that the same reward circuit in our brains that we use for survival and defence is also used for our motivations at work. So if I am motivated by Autonomy (the ‘A’ in SCARF) and someone at work attacks my sense of autonomy in the workplace (by, for example, micro-managing me) I will have the same neuro-response as if they made a direct attack on my life – including the release of the related neurochemicals, in this case, cortisol, the stress hormone. Similarly, if something happens to reinforce my sense of autonomy (for instance, an event I created has an excellent turn out and feedback) I feel great and get a nice rush of dopamine.
DevOpstastic Tip ~=>
Have a SCARF workshop with your team(s) and ask everyone to complete this self-assessment first, share the results and discuss. We don’t always agree with the results of this assessment tool but finds that only adds fuel to the fire of debate.
My key takeaway here is that we should try to understand ourselves first, and then those around us (a bit more ‘fluffy’, but this is about mindfulness). Having this level of insight into ourselves and our colleagues means that when conflict occurs we have a better chance of taking a breath and understanding what’s really going on, remembering we share that common goal and working closer together, collaborating to reach it.
We’ve more recently also starting working with unconscious bias – we’d love to hear from you if you have any experiences in this area.
DevOpstastic Tip ~=>
If you want to know if you have unconscious bias you can test yourself using Harvard’s online Project Implicit testing tool.
3. Eliminate Blame
Let’s start by watching one of my favourite DevOps videos – here you are:
[youtube http://www.youtube.com/watch?v=2PjVuTzA2lk?wmode=transparent]If we’ve taken on board tips one and two and are now in a ‘circle of trust’ we should be able to avoid this kind of finger-pointing blame game. There is no place for blame in a DevOps culture – it is a pointless waste of emotion. We need to understand what went wrong in a retrospective but the most important thing is how to make sure it doesn’t happen again.
DevOpstastic Tip ~=>
Try running a blame free post mortem/retrospective next time you have an outage. Here are some retrospective plans you might want to road-test.
4. Embrace Smart Failure
In order for businesses to thrive, survive, even, in today’s uber-competitive markets, innovating at speed is an imperative. When we are assessing organisations’ DevOps cultural maturity, one of the features we measure is the organisations’ capability to ‘dance around the edge of failure’. Innovating at hitherto unseen velocity introduces a whole host of risk that must be mitigated. Systems need to be created that can warn and pre-empt failure and capabilities need to be implemented to do things like instantly redeploy a last known good state or working version of an application in the event of a failure. In no way are we suggesting that failure should be celebrated.
In addition to creating an safe environment, where failures are quickly and easily fixed, you can also prepare for failure by spending some time prioritising features and architecting applications in a composable manner – for example, your business transactions are probably more important than your social feeds. At a recent workshop we were told a story of how the French railways online ticketing application was down for three days due to a problem with its analytics – if the components weren’t so tightly coupled, the users wouldn’t have suffered as the reservations system could have been operating standalone.
DevOpstastic Tip ~=>
Study Netflix’s Chaos Monkey approach and identify a way to test failures safely in your infrastructure.
5. Focus on Bottlenecks and Flow
If you’ve read The Phoenix Project you’ll know all about The Theory of Constraints – our favourite summary of the concept is that “Any improvement not made at the constraint is an illusion”. Work hard as a team to identify the real constraints – and watch out for that common pitfall as described via the Brent character in the book that those people who often look like heroes are, in fact, your bottleneck. Try to understand the real value to your business of each improvement and prioritise them accordingly.
DevOpstastic Tip ~=>
Try playing ‘Featureban’ – exercise #7 in our DevOps LiftOff Workshop
Don’t be afraid to rethink your process or find a new pair of eyes to see the things you can’t because you are too close. Check out this video to see the improvements motor racing have made to their process over the last fifty odd years – check out the resource utilization, perfect process and automation in 2013:
6. Eliminate Unplanned Work
Another major topic from The Phoenix Project and a universal complaint we hear from organisations when we start working with them: “How do I find the time to save time?”. People know their processes can be improved and there’s a good chance automation could exploit advantages even further but if the culture is to keep doing things that are breaking and broken it’s tough to put aside the hours outside of the firefighting to make DevOps happen.
It’s nigh on impossible to tell a business they can have innovation or support but not both but it’s sensible to get a handle on the projects running and the resources available and the volume of unplanned work coming through the pipe. Some lower priority projects may need to go on hold while the DevOps project has higher priority – this will probably need to be mandated from management and have a solid case behind it that all subsequent projects will be accelerated as a result once the foundation has been laid.
DevOpstastic Tip ~=>
Read The Phoenix Project – what on earth are you waiting for?!
7. Be Continuous
There a lot of these out there – we’ve seen continuously:
- integrate code
- test
- integrate
- deploy
- deliver
- fund
The idea is to always have software in a shippable state and have a DevOps toolchain capable of deploying on demand – have your software development lifecycle like a manufacturing pipeline.
Our favourite here though is ‘continuously fund’ – as Forrester say:
“Organizations that deliver at rapid release cycles create a stable basis for funding a continuous stream of innovation. They use customer feedback and business priorities to continuously prioritize the capabilities that will result in the greatest business value.”
DevOpstastic Tip ~=>
Try setting a pre-approved innovation budget and short, iterative approval cycles rather than annual, large project driven budgets.
8. Form Dedicated, Cross-Functional Teams
Lots of people ask us about creating DevOps teams, something we think it mostly counterproductive as it has a tendency to create another silo. However, there are challenges here as it’s impossible to make everyone a master of everything, particularly in the case of more complex technologies. Simpler technologies can have the advantage of bringing people closer to business.
We recently held a workshop with Jonny Wooldridge, the CTO at The Cambridge Satchel Company where we discussed the DevOps team he built and managed during his time at Marks and Spencer. Jonny’s team acted more like a ‘tiger’ team, where key resources could be drafted into project teams as needed to evangelise the DevOps way and help cross-skill through the project lifecycle.
DevOpstastic Tip ~=>
When you are considering bringing on a new technology, consider the time to mastery – the shorter this is, the better chance your team has for cross skilling for it.
The key is to get everyone thinking in a DevOps manner and cross-skilling and obtaining mastery as time and resources allow – but arrange your resources around projects, rather than their core skillset.
9. Love Transparency
The adage says that knowledge is power – but this isn’t always the case. Sometimes you are better off sharing your knowledge – not only may you gain respect and credibility, you may find that the team around you are able to then work faster to achieve your shared goal – and encourage others to share their knowledge with you too. We can’t possibly all know everything but if we keep things to ourselves, we are often stymying the performance of our team and therefore ultimately ourselves.
DevOpstastic Tip ~=>
Write a blog post about an area of your work you are passionate and enthusiastic about. Share it with your team. Share it with the world. Repeat.
Knowledge hoggers can often be bottlenecks – for instance, we often see cases where an individual has had responsibility for a deployment process, become bored of repeating it manually and written scripts to speed it up – and more scripts and more until they have a ‘script-monster’. Now they are the only person that can possibly understand this part of the process and when anything goes wrong they’re the only one that can fix it – what a hero! If a person is motivated by Certainty (back to SCARF) they’ll certainly enjoy the sense of security and indispensability it will give them – but it’s not so helpful for the rest of the organisation as now they are a serious bottleneck.
Transparency and visibility are features of DevOps cultures and, going back to tip 2, Understanding Motivations, those of us motivated by fairness will feel happier in a culture of openess and equality. Secrets can be very counterproductive and alienating.
10. Build Autonomy, Mastery and Purpose
Changing your culture will probably mean you need to revisit the way you target and reward the people in your business and review the goals you have set, ensuring they are not in conflict and there is a clear, single goal everyone can focus on. The psychology of rewards may surprise you – have a look at this Ted Talk from Dan Pink.
You need to be able to create a working environment where people feel they have autonomy, mastery and purpose – these are the ultimate rewards. Take a look at this blog for an exploration of DevOps goal setting and rewards in more detail.
DevOpstastic Tip ~=>Have you heard of The Illusion of Control? If not, spend a little time researching it and imagining how it could affect your outputs at work.
What’s your top tip for making DevOps cultural change happen?
