CALMS is a framework that allows you to assess your company’s ability to adopt DevOps processes, as well as enables you to measure success during a DevOps transformation.
DevOps goals include:
- Implement an inclusive culture that brings all teams together.
- Automate code testing, automate workflows, automate infrastructure, and fundamentally, automate everything.
Assess your skills and progress with regard to DevOps
CALMS stands for Culture, Automation, Lean, Measurement and Sharing. But what exactly do these buzzwords mean?
CALMS at a glance
- Culture: Organizational silos lead to blockages in your company. Before these silos can be broken down, a culture of shared responsibility and collaboration must be established. Only when all product stakeholders work together can further steps be considered.
- Automation: This is where teams looking to adopt DevOps should dedicate themselves to automating as many manual tasks as possible, especially with regard to continuous integration and test automation.
- Lean: Development teams use lean principles to eliminate unnecessary consumption of resources and optimize the value creation process, such as minimizing WIP, improving visibility of deliverables, and reducing the complexity of handoffs and wait times.
- Measurement: The organization is dedicated to collecting data about its processes, deployments, etc. to understand its current capabilities and identify where improvements can be made.
- Sharing: A habit of openness and sharing within and between teams (supported with the right tools) ensures that everyone is working towards the same goals and reduces handover friction when issues arise.
CALMS – Culture
DevOps isn’t something you can just quickly implement. It’s a culture that affects your entire IT. Every team, from product management, development and operations, to the way you manage your IT infrastructure.
The nature of DevOps is to link different departments together to encourage sharing and collaboration. Automation and tools are “nice to have”, but after a certain point they are useless if all stakeholders from IT and Operations do not work closely together.
DevOps doesn’t solve problems with tools here, it solves communication problems.
Therefore, you should see DevOps much more as an improvement of your agile way of working. Meaning: All teams pull together with one goal in mind.
This means that every person involved in the product must be brought on board. Product management, development, operations, quality management, customer success and all other stakeholders involved.
Consider reorganizing your teams. Move away from functional teams (development, operations, infrastructure, etc.) to product teams. You should make sure that all team members involved in the product can work together seamlessly. In this way, you can break down blocking silos.
It is important to work together towards a common goal and have a clear plan on how to achieve it.
Not always is such a drastic move to product-only teams the right approach, and it can also quickly lead to further problems. Since you can’t always bring everyone on board from the beginning.
Small steps to a DevOps culture
To make DevOps succeed and start a culture change in your teams, you can start by implementing the following practices:
- Collaborative Sprint Planning: As a developer, invite Operations to your regular sprint planning sessions as well.
- Conduct daily stand-ups with all involved stakeholders
- Operations teams can invite developers to their meetings
- Product managers sit at the interface between (end) customer and development. However, top-down communication alone is of little help here. Therefore, introduce a joint meeting or kickoff to determine all possible implications that innovations, updates, etc. have.
So you see, communication is the be-all and end-all in DevOps. Without good communication, the individual goals in the departments (or teams) and the company goals are difficult to achieve.
Our Best Practices for DevOps Culture
At XALT, not only development and operations are involved in the DevOps culture, but the entire company is part of this change and lives open communication. All teams and functions are part of the strategy.
In addition to DevOps and product management, sales, marketing and consulting will be involved in the communication.
This enables us to harmonize the most diverse approaches and to work together towards a common goal.
We thus extend the DevOps approach with the Flywheel method.
The term DevOps is therefore actually too narrow for us. The open communication structure enables us to respond to any external impact and solve it together. For example, customer satisfaction doesn’t just affect Sales or Customer Success, but the entire company. And we respond accordingly.
CALMS – Automation
A fundamental concept of DevOps is the automation of recurring tasks and processes along product development. Implementing DevOps means automating everything in order to free up resources that can then be used in other important places.
You can start by implementing build, test, deployment, and provisioning automation. These are typical starting points for teams at the beginning of your automation journey. Because think about it. What better way to free up all the stakeholders involved to work together on solutions that benefit everyone?
But what is the best way to start with automation? Where do I generate the most added value for my team and company?
The Continuous Delivery approach allows you to ensure that only code that does not contain bugs and lead to further bugs or problems in the software goes live on the production system by automatically testing new code for issues or security breaches. The majority of this approach is supported by dedicated cloud infrastructure. Automated testing also helps developers and operations teams save more resources.
But why are automated tests so valuable?
Computers are able to analyze new code faster, more effectively and more securely than any human. In addition, this allows you to run multiple tests in parallel. This way, not only bugs but also security risks are detected faster. And you can react directly to them and decide for yourself how you want to proceed.
Another big advantage of testing is also that there is no big surprise at a release. Automated deployments also alert IT to discrepancies between environments.
Configuration / Infrastructure as Code
Another option to start with automations is “Configuration as Code”. With this approach, you automate the configuration of your infrastructure (in the cloud), so to speak.
Similar to how you as a developer divide software into small parts that all function redundantly and together represent your app, your infrastructure can be structured in the same way. Depending on what your infrastructure needs are at the moment, it can be easily adjusted, booted up or shut down by making simple changes to the code (configuration). This allows your operations team to provide infrastructure only when it is needed (and to what extent).
These two examples give you just a small taste of what is possible with DevOps. However, the concept can be thought even further. Using blue-green deployments, for example, it is possible to have multiple instances of the same system running in parallel. While one of them is accessible to users, the other is used for testing new functions, updates or hotfixes. This way, the production system always runs stable and updates only go live when the new code runs error-free.
Here you can find more information about Blue-Green Deployments and DevOps.
CALMS – Lean
Since the culture of DevOps is the cornerstone, that’s where Lean comes in. Lean addresses the principles of agile delivery. It ensures fast processes and smooth workflows and brings responsiveness to your cloud DevOps organization.
The DevOps culture allows you to identify opportunities for continuous improvement everywhere. Some of these are obvious, such as regular retrospectives to help improve your team’s processes. Others are more subtle, like A/B testing different onboarding approaches for new users of your product.
It should be assumed that sooner or later mistakes will be made. Therefore, it is advisable to work towards identifying these mistakes quickly and fixing them even faster, and to learn from them in a retrospective.
The magic word here is: Continuous Improvement. So only when you learn from these mistakes, you can improve your processes and approach.
CALMS – Measurement
Now that you have internalized and are using three parts of the CALMS framework, it’s time to take it one step further. Collect all relevant data.
Without data, it will hardly be possible for you to recognize possible errors, problems or blockades.
Fortunately, there are a number of tools and technologies that allow you to measure the performance of your teams or processes.
Data like: How often your users use your product or how often critical system errors occur. However, that’s not all. You can ask almost any question you want and get valuable data from it. Also, the best way to ensure that performance can be monitored on an ongoing basis is to embed data collection into your automation pipeline from day one.
To give you a first idea of what data you can raise, here are some examples.
Data collection questions:
- How long does it take from development to deployment?
- How often do bugs or errors occur in the software?
- What is the MMTR (Mean time to Recovery) of critical system errors?
- How many active users are using the system
- How many users report bugs or errors?
- How often does the system fail?
- How often are updates etc. released?
Ultimately, the more solid data you collect, the easier it will be for you and your team to improve. In addition to the questions above, you can also determine the level of user satisfaction. This is where SLA’s (Service Level Agreements) help you.
Regularly respond to your users and actively ask about any problems and requests for improvements. These will help you further plan your product roadmap and prioritize tasks.
Example product improvement and data collection:
More and more users avoid your software and also cancel their monthly subscription or premium version. The churn rate goes up and up. The question you then ask yourself is, “For what reason are we losing users?” Is it lack of features? Too many bugs? Too much technical debt? So first determine the exact reason. And then take the necessary steps.
CALMS – Sharing
Sharing information ties in strongly with the culture section of the CALMS framework. In the context of DevOps, however, sharing also means a culture of openness and trust. Above all, it is about sharing all information and best practices, making them available to every stakeholder. This then also leads to the sustainable dismantling of silos in your company.
Learn more about enterprise knowledge management in our webinar.
Culture and information sharing is one of the most important parts of the entire DevOps methodology and is the foundation of structural change in your organization. Silos between departments and lack of information for involved stakeholders ultimately lead to frustration and further dislocation in the company. In the worst case, this even has a negative impact on the company’s goals.
A few hard facts about DevOps and why modern IT organizations swear by it
- 60% of developers are releasing their code 2x faster than before thanks to DevOps – a 25% increase over 2021.
- 72% of security professionals rated their company’s security efforts as “good” or “strong” – a 13% increase from 2021.
- 56% of Ops team members said they are “fully” or mostly automated – a 10% increase from 2021.
- Nearly 25% of respondents said they have fully automated their testing – a 13% increase from 2021.
- 75% of teams use or plan to use either AI/ML or bots for testing/code reviews – a 41% increase from 2021.
Source: Gitlab DevOps Report 2021
If you want to learn more about DevOps, take your DevOps efforts to the next level, or automate more even more. Then get in touch to learn how we can help your business move towards a truly cloud-based DevOps culture.