The CALMS Model: Assessing Your Readiness for a DevOps Transformation

If you’re considering beginning a DevOps transformation, we recommend starting by identifying where you are now and where you need to improve before moving forward. This initial process highlights potential barriers that could slow the transformation or make it fail altogether. At 2nd Watch, we rely on the CALMS Model to comprehensively assess teams and processes as a starting point to a DevOps transformation.

What is the CALMS Model?

Originally developed by Damon Edwards and John Willis, and later enhanced by Jez Humble, the CALMS Model assesses your business today and throughout the DevOps transformation. The Model addresses five fundamental elements of DevOps:

  1. Culture: Collaborative and customer centered culture across all functions.
  • Is there a top-down effort to shift culture?
  • Are developers working with app owners, operations, legal, security, or any other department that will be affected?
  • How does your management team support the omni-directional integration of teams?
  • Do you enable the team to fail fast?
  • Is the team encouraged to continuously learn? 
  1. Automation: Remove the toil, or wasted work, with automation.
  • How much toil is present?
  • Is your continuous integration (CI) and continuous delivery (CD) pipeline flowing?
  • Are processes automated efficiently?
  • Is infrastructure automated and available on demand? 
  1. Lean: Agile and scrappy teams focused on continuous improvement.
  • Can you visualize your work in progress?
  • Where can you slim down?
  • Can you reduce batch sizes?
  • Can you limit your work in process? 
  1. Measurement: Data is critical to measure progress.
  • What are you measuring and how?
  • How do you determine progress, success, and the need to optimize?
  • What are your goals? 
  1. Sharing: All teams teach each other and feel empowered to contribute.
  • How is information and tribal knowledge captured and shared across teams?
  • Do teams feel comfortable sharing unsuccessful experiences for learning purposes?
  • Do teams share duties and goals?

Not only is the CALMS Model easy to use and comprehensive in a DevOps transformation, but it can also be applied to any other transformational effort. If you want to reduce costs, increase speed, or receive the benefits of these changes, use the CALMS Model as your foundation to assess where you are and where you are going.

Starting small with the CALMS Model

A good way to begin any DevOps transformation is to start small. Select a group of teams willing to prove the concept and complete a CALMS assessment within their departments. Choose up to five different teams and let the results of the assessment determine the top one or two highest functioning teams. These teams will serve as your subjects for an internal case study to showcase your readiness and chart a larger scale plan.

While proof of concept is important for buy-in, it’s also valuable to bring the right people along the change curve. Invite your IT executives to get onboard with DevOps and understand the entire transformation, rather than just the tooling. It’s not just CI/CD, it’s removing barriers, implementing analytics, and, most importantly, achieving the benefits of the DevOps transformation.

The best way to bring IT executives into DevOps is to help them justify the means. Show them the reduction in costs, increase in speed, efficient resource allocation – whatever your goals may be – as well as the measurements you’ll use to prove that value. Of course, the CALMS Model has these points built-in, so it’s a good tool to use for all stakeholders in the DevOps transformation. Present your findings to IT executives and let the assessment determine if you’re ready to move forward. Not only does the CALMS Model support each DevOps value, it enables measurement both upfront and throughout your transformation allowing you to prove your return on investment.

If you want a successful DevOps transformation complete with assessment and strategy, infrastructure as code essentials, CI/CD, and cloud native application modernization, schedule a briefing with one of our DevOps experts to take the first step.

-Stefana Muller, Sr Product Manager, DevOps & Migration

4 DevOps Myths Debunked

DevOps is a set of cultural values and organizational practices that improve business outcomes by increasing collaboration and feedback between teams. Of course, there are industry best practices, but a DevOps transformation will look different and yield different results for each organization, depending on its business and strategy. With a lot of options and moving parts to a DevOps transformation, don’t let these myths delay beginning your transformation.

Myth #1: Tools will solve your DevOps problems.

Unfortunately, even the best tools are not going to solve all your DevOps issues. Tools are enablers that assist in removing unnecessary toil, but they can’t magically make things perfect. For instance, implementing an automation tool sounds like a great time and resource saver at first glance. However, the tool can only produce those results if the structure around the tool can accommodate the action. If your team isn’t ready for that speed, you’ll likely just speed to failure.

Don’t put the tools before the structure. Instead, think long-term and comprehensively when constructing your DevOps transformation map. Otherwise, roadblocks will slow down your ability to achieve speed.

Myth #2: You should start with CI/CD.

Typically, people begin their DevOps transformation with continuous integration (CI) and continuous delivery (CD). A CI/CD pipeline enables fast code changes through automated deployment steps that create a more consistent and agile environment. While the results of CI/CD are the goal, starting there doesn’t take into account the support necessary for successful implementation.

Today, the DevOps transformation is being refined to include discussions and planning around the evolvement of production support, application monitoring, and automated dashboards. When you start with CI/CD, you’re focused on development speed, but operations might not be ready to accommodate. In true DevOps fashion, you need to bridge the gap between development and operations first to produce a streamlined feedback loop. Operations must have their tools ready to feed into the CI/CD pipeline to break down barriers early on and avoid stopping points in the future.

Myth #3: DevOps transformation and cloud transformation can’t happen at the same time.

Promises of more speed and lower costs motivate businesses to jump into the cloud quickly, with the expectation that those benefits and return on investment (ROI) are delivered immediately. The issue with this way of thinking is not enough forethought prior to action, with a fracture resulting between departments. Teams need to be trained on new cloud procedures, security must be implemented, legal has to update contracts, and company culture, from the top down, needs to be onboard for adoption.

Fortunately, there’s a lot of overlap between a DevOps transformation and a cloud transformation. In fact, DevOps can be the support you need for a successful cloud transformation without any roadblocks. Instead of waiting on DevOps because you’re not agile yet, start with it at the beginning of your cloud transformation. Utilize DevOps best practices as you migrate to the cloud to help transform how your teams work with a well-constructed plan for company-wide implementation.

Myth #4: The role of security is for vulnerability scanning.

Waiting until you’re finished with development to include security is a DevOps anti-pattern. As an essential part of the business, security can contribute more than just vulnerability scanning before you go live. When you only look to security for the last line screening, you’re inviting a significant bottleneck into your process.

Of course, getting security involved and excited about DevOps can be a struggle because they’re inherently at odds. The goal of DevOps is to increase speed with new tools. The goal of security is to decrease risk, which can slow processes and releases. But when you apply speed and change with new implementations, you are increasing risk. Instead of asking, “How do we get security involved before vulnerability scanning?” consider the benefit of getting development to include security as part of the CI/CD pipeline. Automate steps like vulnerability scanning, secrets detection, license checks, SAST & DAST early in the development cycle so that issues are found and addressed early on. This removes the security roadblock to production.

In addition, cross-training between DevOps and security invites both teams to understand their colleagues’ goals, responsibilities, roles, expectations, risks, and challenges. Give each team real life examples of how the gap creates conflict for each side. Once they have a better understanding of the other side, they’re more likely to consider one another during product planning and development.

One well-known and widely accepted truth to a successful DevOps transformation is the benefit of an expert partner in the process. 2nd Watch offers packaged service offerings to help you get the most out of your DevOps transformation with start to finish essentials that deliver the results you expect. Contact Us to see how you can gain more leverage with less risk.

-Stefana Muller, Sr Product Manager, DevOps & Migration

 

A DevOps Transformation Overview: What, How, Who, and Why

When your organization needs to address a specific problem, change the status quo, follow new trends, add a premier service, etc., it requires an approach that leads to success. A DevOps Transformation is the modern IT leader’s choice for achieving the speed and innovation needed to meet today’s market demands.

What is DevOps?

DevOps is a set of practices that combines software development, ‘Dev’, and IT operations, ‘Ops.’ The term was spurred from the initial struggle that existed between these two vital pieces of product creation. However, as our technology has expanded and become more business focused, so has the term.

Initially, businesses were mostly focused on making development and operations work better together by providing appropriate processes and specific automation technology. However, over the nearly 12 years that this term has been in existence, businesses have grown, and we’ve realized that the struggle doesn’t just exist between dev and ops, but rather the entire structure of the business.

How has DevOps evolved?

DevOps grew from the agile transformation effort where companies had to speed up, find new ways to develop software, and go-to-market quicker in order to remain competitive. Although agile was initially a development methodology, it makes sense that we now use it as part of a DevOps Transformation, expanding the use of agile across business areas to help companies quickly deliver the highest value to their customers.

Another big evolution in DevOps is how information should flow. DevOps used to encourage a bi-directional exchange between developers and operations, but now it’s omni-directional throughout the entire organization including departments like security, finance, marketing, product management, and business-line owners. It’s important to expand the feedback loop to and from all the stakeholders in an organization – including your customers – in order to fully deliver high value products or services.

If departments are unable or unwilling to share their wins and losses, communicate candidly, and exchange information, the transformation will hit barrier after barrier. This is especially important for project management, which has to change its processes drastically in a DevOps Transformation in comparison to a department-specific or smaller scale project. With the main objective being speed, planning is critical.

Who is involved in a DevOps Transformation?

The short answer is everyone. When you go through a DevOps Transformation, your company is essentially speeding things up. Typically, the action takes place in the application development and cloud operations space because that’s where you develop and deploy new products or features. But it’s not just the traditional Dev and Ops teams being affected by the transformation. Executives need to be all-in to encourage cooperation throughout the organization. Finance has to transact quicker, sales needs to sell differently, marketing has to understand new features and find the best ways to promote them, and legal has to update contracts with clients and providers to enable the rapid change brought by this model.

Today’s DevOps Transformation affects almost every business area in an organization, including cultural values, organizational practices, and improving business outcomes by increasing collaboration and feedback. This is why we refer to it as a transformation rather than an implementation – it’s really going to change your entire business.

Why are so many companies choosing DevOps?

A DevOps Transformation isn’t the only way to approach change management, but beneficial outcomes are making it a popular one.

  • Streamlined processes: Remember that the foundation of DevOps is built on removing the struggle between departments. Enabling teams to cross-innovate, by eliminating barriers and encouraging a culture of constant innovation, propels your business forward faster.
  • Challenges resolved: When your approach is based on removing issues and facilitating an omni-directional exchange of information, you get an unencumbered view of what those issues are and can then work toward resolution.
  • Specific benefits achieved: DevOps is used to target specific goals, and with the measurement necessary to determine success, IT leaders inherently receive a slew of additional benefits. For example, if you’re using DevOps to address high development costs, you won’t only accomplish cost reduction, but also faster time to market and higher security in your development cycle.
  • Valuable data collected: DevOps requires you to measure, report, and be transparent with everything you do. These insights not only aid the DevOps Transformation currently in focus, but also future initiatives.
  • Elevated customer experience: Delighting your customers with new, stable technology on a frequent basis will contribute to retention and new business growth.

2nd Watch has developed a number of DevOps Transformation services to aid enterprises in their transformations, including assessment and strategy, training and tooling, continuous integration and continuous delivery (CI/CD), cloud native application modernization, and full DevOps management. Get more out of your DevOps Transformation while becoming self-sufficient for the future. Contact Us to discuss how a DevOps Transformation can help you achieve your goals.

-Stefana Muller, Sr Product Manager, DevOps & Migration

DevOps: Getting buy-in

Understanding what DevOps means and brings to the business is critical in order to get buy-in at the beginning of the process, but also to ensure that all teams are fully engaged with an ongoing process that requires the whole organization to be on board.

Getting buy-in for DevOps may be your greatest challenge in the implementation process. There are three key groups of people you need to get buy in from: executives, engineering and operations teams, and middle managers.

Executives:

Executives is the most important group to get on board early – in particular because they can be instrumental in preparing other parts of the business for the DevOps implementation.

To get executive buy-in, lead with data and show (and prove) the waste and inefficiencies in your current processes and how DevOps can solve this.

Alongside this, align the proposed DevOps implementation with the company vision, such as reducing costs or moving to the cloud. Demonstrate how these things require a DevOps mentality to be successful.

You should also align with executives’ visions. Find out what each executive’s concerns, challenges, and goals are and explain how DevOps can help them reach these objectives.

Engineering and Operations Teams:

Identify problems engineering and operations teams are facing and where they’re struggling. Then provide solutions that are actionable and tie in with DevOps practices. It is important to show these teams first-hand experience of DevOps successes and give evidence of where other organizations have succeeded with DevOps.

From here, provide solutions and basic guidance that are actionable and will enable team members to solve the identified problems utilizing DevOps practices. For engineers and IT admins, first-hand experience is critical.

Also, reassure engineering and operations teams that with a DevOps culture their jobs are safe. Change is often associated with staff cuts, so let the teams know that DevOps will not impact job security but will allow them to focus on more valuable work.

Show the engineering team how they will have more features with less rework and will no longer face blockers in the process. DevOps will enable them to do their job.

For IT operations, meanwhile, let them know that they will get more proactive work done, which means fewer alerts and fewer tickets because they will be able to address problems before they arise. There will also be less manual work, with feedback incorporated into the product.

Middle Managers:

These team members are the most difficult to convince and are typically late to adopt, so trying to gain early buy-in may be tricky. Try sharing real results from other teams and exerting some peer pressure from above and sideways. You can also ask this group why they are hesitant, with a number of ‘why?’ questions.

DevOps can bring valuable advantages to your business, but it must be supported organization wide. Getting buy-in for DevOps is just one of the common challenges to the implementation process. True culture change required to successfully implement DevOps is difficult, so understanding the misconceptions and challenges before you begin is critical to your success. Download our ‘Misconceptions & Challenges of DevOps Transformation’ eBook for insight into other common misconceptions and challenges to implementing DevOps and guidelines for how you can overcome them.

-Stefana Muller, Sr Product Manager, DevOps