Corporations and DevOps Culture

Sometimes, through Reddit, friends, or other blog posts, I read or hear about corporations that want to adopt a DevOps culture to allow their teams to be more effective and capable of change. They dream of their Operations and Development specialists working together to effectively triage and solve production issues speedily. Reality then slaps their faces and dashes their hopes when it turns out that consultants and process changes haven’t made their dreams come true.

In part, I think this is because many large corporations have executive staff that are too far removed from the codebases that generate value. The business wants specific value generated by certain deadlines and business units far below in the hierarchy end up responsible for the work to make it happen. The necessary requirements of those business units to respond to changes and deliver quality work in a timely fashion are faint echoes by the time upper-level executives hear problems. Upper-level management should fundamentally be aware of, what I consider to be, the two critical components to a DevOps culture, one that enables agility and high-quality work to exist simultaneously: thoughtful codebase organization and blamelessness.

I believe the reason most corporate adoption of Scrum, and other processes, fails is due to a lack of acknowledgement that their codebases are not capable of supporting rapid changes. The processes are taught and implemented without any thought given to the context they are applied within. A well organized codebase is the first critical step to providing agility to the Developer and Operations specialists that have to work together. Well organized codebases provide fast, effective, and informative continuous integration pipelines with ease, and provide valuable local development environments. No process change can fix this, only dedicated development effort.

This development effort has to coincide with blamelessness; no single person should ever be found at fault for any of the future problems that can occur in a project. Blamelessness requires team building – not simply bringing colleagues together. Only when teammates genuinely care about others can you create an atmosphere where questions are constantly asked and answered about codebases. It’s this safety to explore and learn that allows a team to onboard new members quickly, that allows knowledge transfer to occur, and that creates a fun environment. Things fail, people are not oracles, and specialists will always need to lean on each other for support.

These two things, I think, can be highlighted in every corporate failure related to DevOps culture, and even Agile processes. Context is king, and most corporate environments have zero eyes on it.