What does the C in CALMS really mean? #DevOps

In his book: Organizational Culture and Leadership” (1992) Edgar H. Schein defined culture accordingly:

“A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems”.

Or, in short, “the way we do things around here”.

So when we talk about Culture in the DevOps model of Culture-Automation-Lean-Measurement-Sharing (CALMS) what do we really mean? Plenty of presenters at DevOps conference say “DevOps is all about Culture” but very few go on to define what Culture means or what are the characteristics of a “DevOps culture”.

Unless we state explicitly what we think are the characteristics of a DevOps culture we risk people making assumptions about what we think a DevOps culture means, and even more than that we risk not having an important debate around whether those characteristics are valid for all organisation types (public, private, non-profit), sizes (start-up, SME, Enterprise) or national cultures (Eastern versus Western for a simplistic example).

Already I think “DevOps culture” has almost descended into a short-hand for either “the type of culture they have a Google, Amazon or Netflix” (which ignores the significant cultural differences between those 3 organisations) or short-hand for “Silicon Valley start-up culture” (which is probably even more diverse but even in its most mainstream clichéd cultural form is definitely NOT a one-size-fits-all cultural model).

At DevOpsGuys when we look at the Key Success Factors for a DevOps Transformation there several that are talk about aspects of DevOps Culture (e.g. Management Style, Attitude to Change) but what would be on your list?

What does a “DevOps Culture” mean to you? Answers in the comments please!

From… Key Success Factor To…
Command & Control Management Style Autonomous
Conservative Attitude to Change Experimental
Silo Organisation Structure Networked
Project-focussed Delivery Focus Product-centric
Waterfall Delivery Model Iterative (Agile)
Large (Huge) Batch size Smallest possible
Monolithic Systems Architecture Loosely coupled
Proprietary Technology Open (Source)
Manual Processes Automated
Share this:

Leave a comment

Your email address will not be published. Required fields are marked *

*