When someone asks me to explain what DevOps is about, I usually do this using the different letters of the acronym CALMS.
Culture is the foundation of DevOps. If you omit culture, you're only doing some symptoms of DevOps (like using a whiteboard, working in timeboxes and doing daily standup meetings won't make you an Agile team).
Culture is about the people, about self-organized teams, about T-shaped profiles, about tearing down the wall between Development and Operations. A DevOps team takes end-to-end responsibility of an application or system: "you build it, you run it".
If your organization has always been working in a command-and-control style, then the first thing to do is to instill a culture of team empowerment. And don’t underestimate this: this will probably take years to change.
This is where a lot of focus goes into and can be considered as the easiest to obtain. The heart of DevOps is the CI/CD pipeline: the continuous flow process that is triggered upon check-in of new versions of code. Continuous integration was already known in eXtreme Programming. In a DevOps context, the continuous delivery/deployment makes the story complete. To make your CI/CD pipeline work at its full capacity, you have to consider everything as code:
But automation is also about closing the feedback loop: getting observations, metrics from running system fed back into your team’s product backlog.
DevOps is not about moving big chunks of changes to production, but instead, moving to a constant flow of small and easier to control changes. Flow, as in Kanban: limited work in progress, small batches. And moving to the production does not automatically mean: "going live". If there is a dependency with other code that is not yet ready, you can still disable your code via feature toggling until everything is ready to be activated.
This is crucial to improving: define metrics on your process. How good are the things going in your organisation? Where is room for improvement? And the apply the typical Plan-Do-Check-Act/Adjust approach to gradually improve your way of working.
DevOps teams take full responsibility over their system. But this does not mean that they have to reinvent the wheel over and over again. They learn from their peers.
There are plenty of resources on the internet - blogs, pictures, slide decks and videos - that explain DevOps using this CALMS acronym. So by now, this acronym has become common sense for anyone who searched for some kind of definition of DevOps. Or hasn't it…?
DevOps according to SAFe®, in 5 slightly different letters
Recently I had a discussion with a colleague who is a certified SAFe® Program Consultant and trainer. According to this colleague, SAFe® doesn’t talk about CALMS but about CALMR instead. She wanted to be sure we tell the same story and don’t confuse the people we train and coach. I am not going to give a full explanation of SAFe's definition of Devops, you can read it yourself on the SAFe® site (more specifically on this page www.scaledagileframework.com/devops).
But I will briefly explain what the acronym CALMR stands for according to SAFe®:
This discussion made me wonder: if a large part of the world talks about CALMS to define the principles of DevOps, then why does SAFe® talk about CALMR and what is the difference? And why do they call it "SAFe® DevOps"? So I did some investigation and this is what I found.
What's the difference?
In all honesty, whether you speak about CALMS or CALMR, in the end, both are equal, or better, equivalent. Let me explain why.
In the CALMS acronym, the S stand for sharing. Sharing of knowledge, of experiences. Call it communities, or chapters and guilds if you are more into the way Spotify works.
I deliberately don't call it "the Spotify model" because there is no Spotify Model (says Marcin Floryan, a Spotify chapter lead in this presentation: https://www.infoq.com/presentations/spotify-culture-stc).
But that’s entirely different story.
Sharing in CALMR
In "SAFe® DevOps", sharing is a part of the Culture. People work in teams. But teams together form a release train. So, these teams will not only need to align planning-wise, they also inspect and adapt during the IP sprint. And they learn continuously. OK, fair point. But sharing clearly is there in both definitions.
Recovery in CALMS
So, what about the recovery aspect of SAFe® DevOps? Is it a part of the CALMS acronym too? In my opinion, yes, of course, divided over other aspects. The first thing that the SAFe® site tells about Recovery is "Stop the line mentality".
Now, that is a Lean principle. Mary Poppendieck (Lean Software Development) mentions this in her presentations: "The greatest productivity comes from not tolerating defects. Create ways to detect defects the moment they occur” (see slide deck https://accu.org/content/conf2007/Poppendieck-Stop_the_Line_Quality.pdf ).
The other parts, Plan for and rehearse failure and Build the environment and capability to fix forward and roll back, these are typically automation aspects. Plan for and rehearse failure talks about the chaos monkey.
The Simian Army is a bunch of tools and concepts that will create chaos in your ecosystem: kill processes, slow down processing and so on. Chaos engineering is really great, but most likely not the first thing you will implement (even though it is a very good enabler for resilience). More information on the Simian Army can be found on the Blog of Netflix. (https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116).
Fix forward or roll back: these are the capabilities of your CI/CD pipeline, the heart of your automation efforts in DevOps. Your Continuous deployment should allow to roll back changes. Or do canary releases: for certain changes you don't go full park all the way, but deploy on a very limited set of servers/containers as a try-out and roll back if "the canary dies".
I could not find any explanation on the internet why SAFe® talks about SAFe® DevOps. The only thing I can think of is that they want to stress how DevOps culture, principles and practices seamlessly integrate with SAFe®. Similarly, SAFe® talks about SAFe® ScrumXP, where the good practices of Scrum and eXtreme Programming help to deliver good quality software every iteration and every program increment, not only on team level, but integrated with the other teams of the Agile Release Train.
As far as the difference between CALMS and CALMR is concerned: they both cover the same ideas. In my humble opinion, the difference between CALMS and CALMR could be a matter of focus: maybe the initial focus of CALMS was to stress the importance of sharing knowledge, whereas the CALMR stresses more the need to be able to roll back a failing change.
Bottomline, CALMS and CALMR may not be entirely equal, but they are definitely equivalent.
Your email address will not be published. Required fields are marked *