The Four Values of a Devops Transformation
This article was originally published on Cevo's Blog by Steve Mactaggart, and with their permission, we are sharing it here for Codeship readers.
A successful devops transformation sees a change in organizational culture. These changes often come in the way of adoption of specific tools or practices.
However, to change culture, you need something more fundamental than just the introduction of new tools, or pushing everyone into Scrum teams.
Just like the agile transformations of the past, there was a difference between ‘Doing Agile’, and ‘Being Agile’. ‘We do standups’ - therefore we are Agile. Are we ‘Doing devops’ or are we ‘Being devops’?
Agile cultures have evolved to a deeper understanding that it’s not about the team structure, or even the ceremonies, but it is about the values that they hold.
So if we are to be successful with a devops transformation, what are the values we should be aiming to foster, and why are these important in the first place?
We propose that there are 4 key values to a devops culture:
In a classic operating model for any change to occur multiple teams, if not departments, need to come together to make things happen. As organizations grow an even larger number of teams are required until you reach a point where everyone is very busy, but little value is actually being delivered.
No one aimed to build a process that didn’t work, these processes were evolved as a way to encode observed good practice. Their objective was to ensure quality through process. But blindly following a process misses the why. Too often organizations forget why they put these process in place, and start ‘cargo culting’ their delivery approach.
Are we going to fall into the same trap? Are we going to define a set of best practices and approaches, label things and create a cargo cult following of our own?
How do we learn from the failures of the past, especially when learning from failure is one of the key values?
We do this through understanding why these values are good for us, and we create a culture where things are regularly and vigorously challenged. While we are constantly striving to deliver value we need stay focused on ‘Why we are doing it.’
We can start by looking at the four key values and see how they have support for ‘why’ at the heart of each of them.
There are many great resources on the internet that talk to the values of a Lean approach, so we won’t recreate them here.
Devops embraces the values of a lean approach as they are focused on doing enough to deliver value, no more, no less.
“Why work lean” - At its heart, a Lean approach aims to increase value through the reduction of waste. One of the strongest ways to reduce waste is to challenge why we do that activity in the first place.
Forming small cross-functional teams with a lean approach is often one of the first steps on a devops adoption path. These teams are empowered to deliver change in the way they see provides value to their customers, while still being accountable to they meets the goals of the broader organisation.
Ensuring these teams are supported to make changes to reduce waste within the team, and provided a context where they have everything they need to succeed will allow them to challenge the current blockers to delivering value.
Nothing is perfect, and failure is always just around the corner. The only way to guarantee that nothing can fail is to do nothing at all.
While there are some industries that need to take a risk-averse position due to the nature of their work or the impact to society if they fail, most do not. In fact the reverse is true.
In a world where competition is increasing and the needs of customers are only becoming more demanding, the rate of change required to succeed far out-strips the current risk management processes. In this context Failure is inevitable.
“Why embrace failure” - Core to a devops culture is one where we recognize that things will fail. What we need to recognise is it is not the failure by which we will be measured but by how quickly and effectively we respond to the failure
By creating an environment that acknowledges failures will occur, we can prepare ourselves to not only reduce the impact, but more importantly manage the splash zone of the failure.
We aim to fail before the customer sees it. We peer-review our changes, are constantly integrating and testing our systems, and deliver change through automation to increase our confidence.
If things do slip through and our failures become more public, we work in a small, focused team that has the knowledge, skills and access to resolve the issue. We empower, support and challenge them to ask ‘why did this happen?’ in the first place. What could have we done to catch this issue earlier? What are we going to do to make sure this failure does not happen again?
Automation is often seen as the goal, by having things automated we reduce the demands on the people and so we can do more things. But seeing automation as the goal is an anti-pattern. It should be seen as the journey.
Anyone who has done any complex automation activity will agree that sometimes the automation makes the system more complex and more fragile. In those cases the reason is that we have just automated a broken approach.
“Why automate everything” - When we look to automate things we first need to know why we do it, this gives us an opportunity to challenge if this is a valuable step, or just a workaround for another broken process.
When we set an ambitious goal to automate all the things, what we are actually saying is that we want to understand all the repetitive tasks that get done. When done with the right intentions, this forces us to review the current steps and ensure they are aligned to delivering value.
More often than not, an attempt to introduce strong automation only flushes out the dysfunction in the current process. A true commitment to automation is a true commitment to facing this dysfunction and a willingness to change it.
!Sign up for a free Codeship Account
Diversity is more than just a balanced blend of genders in the team. True diversity should encourage a mix of people with a whole range of different backgrounds, be those race, occupation, gender or religion, to name just a few.
For us to truly create teams that able to respond to changing business needs, that can own a solution from end-to-end and strive to deliver the best they can for their customer, they need differing points of view.
“Why diversity” - The right balance of conflict is important to ensure the team is consistently reviewing the current approach and looking for opportunities to reduce waste and deliver more value.
By definition devops is the bringing together of Developers and Operations staff, that alone is more diversity than some teams have had for decades.
Ensuring there is a voice for all aspects of the system involved during the planning, delivery and support of new features will only increase the chance that the right solution will be developed in the right timeframe for the right customers.
Driving a Culture Change
You can see from these four values that there is a depth to each, but combined together they form a strong force for change.
Change that is focused on delivering value to customers by ensuring we build the right thing, can support it and willing to learn from the bumps from along the road.
Change that is delivered with as little delay as possible, in small chunks that let us reduce the impact of failure while enabling us to get feedback from customers rapidly to ensure we build the right thing.
Change that is constantly automating away the common activities, while also identifying ways to improve the process as a whole.
If you are looking to start a devops transformation, or at a point of review of your current approach, don’t start with the tools or the teams, start with the Why, and identify the problem you are really trying to solve.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.