DevOps is a cultural phenomenon. While automation tools and processes all play a part, the most important aspect is the culture. Without culture, all the commonly touted DevOps tools and tricks will fall flat.
If you hope to lead lasting and meaningful change in your organisation, it will start – and ultimately end – with culture. Culture is the catalyst that makes things like Configuration Management, Agile Development and Integrated Processes work.
Meaningful cultural change is not simple or straightforward. This means that it’s easier and more rewarding to focus on shiny new tools and frameworks which give short term gains, at the expense of real cultural improvement. But unlike tools which tend to be replaced every 3 to 4 years, culture can be enduring. A robust DevOps culture can outlive any single individual or team within an organisation, because good culture is self perpetuating.
Build Consensus and Demonstrate Value
Leading a DevOps movement does not require you to be in a leadership position in your organisation, but some leadership precedent on your part will make the process faster and easier. However you must remember that culture imposed from the top down in an authoritarian manner rarely endures. Instead you must seek to lead by example and effect change via consensus.
Dictates passed down without consensus and buy-in from every level will not last, at best they will be complied with and discarded as soon as practicable. Compliance should not be the goal, instead focus on empowering teams, individuals and the organisation as a whole.
Without empowered individuals the organisation will fail to adapt effectively, and in the fast paced world of software development this is suicide. Individuals and teams must be empowered to adapt their processes and tools based on a common set of principles and goals. Organisations which are aligned based on goals and principles are far more adaptable to change than a rigid organisation with well honed but inflexible procedures. The rigid organisation may run very efficiently for a while, but it will not stand the test of time.
Thus the role of anyone hoping to lead an effective DevOps movement becomes part evangelist and part mentor. You must effectively communicate the advantages of the DevOps philosophy – and then demonstrate them – in order to create consensus and build allies within your organisation.
Encourage Constructive Failure
Most organisations are incredibly resistant to change. This is human nature and inherent in most hierarchies. Continuous Improvement – one of the core tenets of DevOps – is always at odds with this rigidity. A DevOps leader should seek to incentivise continuous improvement via constructive failure.
The ability to analyse failures objectively without assigning blame to an individual should be prized above all. Amazon Web Services does an excellent job of this, at least externally. In the rare cases where they suffer a major outage, their postmortems never blame a person, they instead lay out the failure of process that allowed the issue to occur.
This is an extremely important distinction. An organisation that blames individuals for problems will incentivise caution and resistance to change. When human error is an assumption built into your processes, you can begin to look at where the process was wrong rather than a specific mistake that someone made.
Failures of the process should be welcomed as an opportunity to improve the system. They are after all the most important and relevant form of feedback you will ever get.
Actively Solicit Feedback
Without a system in place to actively solicit feedback, teams will tend to coast on established process. Part of your job as a DevOps change-maker is to create mechanisms in the organisation where different types of feedback can be solicited, analysed and acted upon.
One effective way to do this is to hold regularly scheduled innovation sessions where feedback is encouraged. These sessions can be formal or informal. Usually something like a bi-weekly coffee at a local cafe works well if it’s done as a team. Remote organisations will need to get more creative with their feedback solicitation structures.
These sessions should be lightly moderated, but not excessively so. It helps to have a designated person to bring conversation back on track occasionally. This can be a scrum master, team lead or anyone else that is respected within the team. This person should also keep notes, and track the progress of feedback implementation.
Progress should be communicated regularly to the affected teams. When individuals see their feedback and concerns taken seriously, it encourages further constructive feedback. This becomes the type of self reinforcing cycle that creates a lasting and resilient culture of continuous improvement.