DevOps & DevSecOps is more than JUST culture

After a few salient comments I need to expand upon my previous thoughts (DevOps is culture). It is culture, but a dedication to continuous improvement by itself is insufficient to transform an organization. It takes people (with specific jobs and tasks) and technologies to actualize the ambitions of a cultural transformation.

While it was implied my last post, I must be explicit: speed is a consequence of quality and quality is a consequence of DevOps (speed as measured by Time To Build, Time To Value, Mean Time To Recover, etc.). Embracing DevOps and DevSecOps improves quality, improves trust, reduces the manual processes, managing risk, etc. which enable more frequent deployments, greater business value, higher stability and resilience, etc.

And finally, I must emphasize that continuous improvement requires continuous learning. Education is achieved by creating a space of psychological safety, being vulnerable and trusting, gathering best practices, asking questions, sharing lessons learned, mentoring others, etc. So please do your part and share your challenges, share your journeys, learn from and help guide others on their path. DevOps Enterprise Summit is an excellent conference built exactly for this purpose.

People: Jobs and Tasks

A build engineer, scrum master, security administrator, technical architect, quality engineer, chaos engineer, infrastructure engineer, operations support specialist…each is a critical role and all are necessary for the livelihood of DevOps and DevSecOps. But these are individual jobs with distinct specialized tasks, functions, etc. Collectively they contribute to the ideals of DevOps but kept independent they only further the segregation of responsibility and undermine the very underpinnings of the movement. No one role is DevOps, it is everybody’s responsibility.

 I’ve heard the counter argument: If everyone is responsible, then nobody is!

Every time I hear this I think of Syndrome from Incredibles: “when everyone’s super, nobody will be”. Broken down the syllogism follows: responsibility is applicable to individuals, groups are not individuals, therefore groups have no responsibility. That’s the kind of fallacious argument refuted by your parents (“but everyone was doing it” didn’t get you out of trouble), why would you think it is valid now that you’re an adult? Groups are comprised of individuals and individual responsibility does not disappear just because they are assembled into a group. 

A dedication to quality, continuous improvement, security, etc. is everybody’s responsibility and as a collective we do more to germinate ideas and transform cultures than is possible by individuals alone (consider a bee colony, each type of bee has a role/task and by working together they achieve a level of greatness that individuals cannot achieve alone – including the pollination of 80% of the crops we eat!). 

The point: individual jobs, roles, and tasks are critical to the success of the ideals of DevOps but kept distinct they do not create the environment necessary for DevOps and DevSecOps to thrive.

Technology

Technology is an enablement tool. The application of technology does not suddenly transform a Waterfall organization to DevOps. The erroneous implications of sites like “Azure DevOps” and “AWS for DevOps” lead one to believe that simply applying a set of tools is sufficient to declare “DevOps accomplished!”. It is too easy to ignore the articles produced by those same cloud vendors (What is DevOps and coincidentally What is DevOps) which help to explain more of what it is while still selling their flavor and technologies. 

Interlude: both of those articles mention cloud and deploying micro services as part of their definition of DevOps (and why stop at micro instead of lambda/functions?!). Following this, any team deploying to internal servers or deploying a monolithic or legacy architecture cannot be DevOps. That is a very self-serving definition and ostracizes the large number of enterprises/teams that have adopted the spirit of continuous improvement and deployed processes and technologies that are endemic to the movement but are working with a legacy stack / internal infrastructure.

Back on track: technologies which enable better testing (e.g., Spock), repeatability (concepts such as infrastructure as code — e.g., Chef, Docker, etc.), improved project management (e.g., Azure Boards, Jira Align, etc.), improved code scanning (e.g., Contrast Security), stress the application/environment (e.g., Gatling, Simian Army, Toxiproxy), leverage real-world learnings to further strengthen the environment (e.g., ChaoSlinger), provide a view into execution (e.g., Dynatrace, Splunk, ELK stack visualizations, etc.) etc. are critical to the evolution of DevOps and DevSecOps. Without leveraging these technologies (the concepts thereof) the organization will continually chase the ghost.

The point: technologies enable, technologies advance, but technologies alone do not create the environment necessary for DevOps and DevSecOps to thrive. 

Concluding thoughts

DevOps/DevSecOps is not a job or task implemented by an individual. DevOps/DevSecOps is not the application of a technology stack.

It is a way of thinking, behaving, and believing. The purpose of DevOps and DevSecOps is to improve holistic quality through education, understanding, compassion, mutual accountability, and most importantly continuous improvement. To achieve the goals of DevOps and DevSecOps one must leverage specific roles/functions (people) and tools (technologies), but most critically one must commit to the ideals of continuous improvement and transform the culture of an organization (note: I did not call out process change because it is tacit to continuous improvement – one cannot continuously improve while retaining archaic execution models).

The point: DevOps& DevSecOps is an organizational culture achieved through persistent application of continuous improvement ideals which are supported through specific roles, functions, technologies, and processes.