CALMS Soup for the DevOps Soul
A bit of forewarning, I won’t be talking about soup. Hopefully though, like a bowl of chicken soup, I will be able to calm your nerves about the most complex aspect of DevOps.
But first, let me talk about crime. By 1990, New York City had hit an ominous record of 2,245 murders. The New York Police Department (NYPD) seemed unable to stem the rising crime rates. It took an eccentric by the name of Jack Maple to radically shift the NYPD’s culture and approach to policing, reversing the cycle of crime engulfing the city.
As told in this Reply All episode, Jack was a self-described “crookologist” who decided to fight crime through data. While stuck in the lowly Transit division, he used his wall maps to eliminate a crime spree on one subway line, then all the subway lines, and then city wide.
Today crime in NYC is at its lowest levels since World War II. The system Jack put in place, COMPSTAT, completely changed policing and the culture of policing to one that treats every serious crime with the same level of diligence and responsiveness regardless of demographic*.
Culture change is hard. Getting one of the world’s largest police forces of 40,000 officers to change how they tackle crime seems nearly impossible. Often trying to make changes an in organization a fraction of the size and complexity seems just as daunting.
Change is not the natural state of mankind. We enjoy our peaceful state of inertia, a finding backed by neuroscience. The only time we are motivated to change is when presented with something novel or imminently threatening.
Thus the problem introducing change into an organization. When you are the one instigating change, people resent you. When change is coming your way, you resist. And the bigger the organization and longer the state of inertia, the harder it is to change.
When it comes to introducing DevOps, this is the situation most IT organizations face. Having exhausted the useful lifespan of legacy infrastructure and confronted with a much more demanding market, the way enterprise IT deploys software simply does not work anymore.
DevOps was introduced as an answer to the software delivery bottleneck. While Agile helped to improve the structural challenges in software delivery to align customer, business and IT goals, getting code out to production in shorter timeframes is still daunting. Thus the rise of CI/CD tool chains and a strong emphasis on automation and lean practices.
But is automation enough? As I mentioned in a previous post, automation is important but not the first step. There needs to be a belief that automation is worthwhile.
One framework used to access adoption and progress of DevOps is CALMS. It stands for Culture, Automation, Lean, Measurement and Sharing as described below:
- Culture — Alignment on common goals and fostering a continuous learning mind set and willingness to take calculated risks
- Automation — Reducing manual effort and enabling programmable infrastructure to allow for further reduction of inefficiency and defects
- Lean — Implementing processes that reduce complexity while improving flow of work so that output is faster and of higher quality
- Measurement — Leveraging metrics to monitor flow of work so that effort aligns to business outcomes and enables feedback loops for further improvement
- Sharing — Ensuring a collaborative environment that supports the free flow of work, information, and learning across the organization
Each element of CALMS is important in its own right and any deficiencies in one area affects the overall success of DevOps adoption. It’s perhaps not a coincidence though that culture is listed first, because without agreement on common goals, there is no objective purpose or measure of success.
So that begs the question of how does one “implement” culture? The story of Jack Maple and the NYPD sheds some light here:
- One Catalyst — Someone needs to instigate the change, someone with the passion to evangelize the idea and see it through. Jack was completely alone but had conviction to not back down when faced by the backlash of naysayers.
- Identify the Problem — Solutions for solution’s sake do not have impact, a common criticism of technology. You need to solve the problem at hand, and Jack saw the problem that the NYPD was not treating all serious crimes as equally important.
- Clear and Bold Vision — The idea needs to be easily understood and tangible enough to grasp. Jack stated that all serious crimes should count equally and to do so requires a data-driven approach to analyzing and predicting crime.
- Start Small for Big Impact — Most changes initiatives fail because they take a big bang approach. Instead Jack focused on the subways, line by line, to refine and prove his vision. These small wins gave him credibility to then implement the ideas more broadly.
- Measure Outcomes — Vanity metrics make us feel good, but focusing on outcomes drive lasting business impact Jack saw that crime rate was the objective so COMPSTAT meetings were focused on that key metric.
- Build Internal Bridges — Culture change requires showing the value of change, especially in a large organization with competing interests. Stating the vision and showing results, Jack was able to build internal support to hold the critics at bay.
- Secure Executive Support — Organizational change has the most success when backed by executives. When Bill Bratton was choose to lead the NYPD, he gave Jack the authority and support to implement his vision across the organization.
Like CALMS, each of these seven points work in conjunction and are critical to successful culture change. None of this is easy, but having a framework helps to assess the effectiveness of your ability to implement DevOps so that the “ALMS” in CALMS can stick.
How do you measure change initiatives on your team? Is there a framework you use to measure DevOps adoption across your organization?
* There was a downside to this story as it relates to narrow focusing on metrics, which I will talk about in a future post.
Can mathematical operators *, /, +, -, ^ be used to convert a non-zero number to 1?
Takes me back to my Siebel VB scripting days…
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
