DevOps Frameworks
DevOps Frameworks

Culture, Automation, Lean, Measurement and Sharing

In my last article about Why do we need DevOps? I already mentioned a framework that can be used to introduce DevOps in an organization - CALMS.

The CALMS framework was originally invented by Jez Humble, co-author of “The DevOps Handbook” and “Accelerate”. It is used as a means to assess whether an organization is ready to adopt DevOps processes or how an organization is progressing in its DevOps transition.

The acronym stands for Culture, Automation, Lean, Measurement and Sharing.

Although this is my preferred way to assess, the approaches “The Tree Ways”, described in “The Phoenix Project” or “The DevOps Handbook” and “Mature capabilities in technical and management practices” found in high-performing DevOps teams, based on the research presented in “Accelerate” are also mentioned.

Nevertheless, I would like to talk a bit more about the CALMS framework.

What DevOps is NOT

But before I do that, I would like to clarify what DevOps is NOT from my perspective by some debates in my nearer past. I have already mentioned some of these in passing in my last article. However, I would like to emphasize it clearly once again:

And there is one point which, for my personal conviction, must be mentioned. I say it frankly and I stand by it: “DevOps is not a role”

CALMS

Culture

Behind the aspect of Culture, which occurs in all three approaches, hides a complex problem which in many cases is also the main reason for the failure of a product development.

Culture

Before thinking about breaking down silos in an organization, a common view of the entire system and common targets should be in place and a foundation for a common responsibility should be laid. This is key if you want to be successful.

In most cases a common team vision and mission can be helpful and is one of the things that can make the difference. There are of course different approaches to developing these, but what is needed is trust, not only the trust of the team members themselves, but also the trust of management in the journey of DevOps and the ROI that comes with it.

To be able to destroy silos, cooperation must be encouraged. From the history the developers want to get new features into production as soon as possible. But in operation it’s more about being able to run the system as stable and sustainable as possible and not to endanger the stability by changes that have possibly hardly been tested. Thus the two statements from the history stand in contrast to each other. Which in some cases can lead to points of friction in communication. Which I will not go into here, I think you know the points of discussion.

That’s why it’s important to get everyone involved as early as possible and create a “You build it, you run it, you own it” mentality. The way a system is operated finally has an impact on the architecture and on the cooperation between components. If a system cannot be operated, it is ultimately doomed to failure.

Products where all parties involved have an open and encouraging communication culture are also the products that will be on the market in the coming years, other products have already disappeared due to lack of maintainability and many other aspects.

With the open culture comes transparency in communication. Successes as well as failures are part of this culture and are celebrated one way or another. Failures lead us to improve in what we do and to continuously work on ourselves, to learn something new and to improve our processes, our daily work.

Even though sharing successes and failures are actually more part of Sharing, they are deeply rooted in the culture. Teams that are not familiar with this culture can slowly be introduced to these aspects through games and a lot of motivation. Decisive for this is a non-blaming culture and the open discussion, the open ear of the team members and management.

Herewith I am approaching the end of the cultural aspect, even if there is still a lot to tell, to be fair. The last point I would like to mention is the topic of team structure or team constellation.

I have seen many companies that always seemed to be seeking the same stereotypes and thus inevitably created one-dimensional thinking. But to be successful, you need different types in a team. This does not start at seniority level (junior, professional, senior). It is an advantage to have different skill sets in one team. What I want to create are cross-functional teams that cover the complete software development life cycle and thus represent the non-plus-ultra for my system.

What it does not mean is that a team should only contain specialists and hard-to-manage individualists. It should mean that in order to develop successful products, it needs not only specialists in their field of expertise, but also generalists who can possibly cover one or more main areas of the SDLC.

Automation

To put it simply, DevOps teams should strive to automate as many manual and recurring tasks as possible. Attention should always be paid to stability, maintainability and simplicity. There are a few points that can be addressed under the main topic of automation. Each of the following principles separately fills whole articles and books, so I would have liked to mention them but will not go into all of them in detail:

Automation

Automate the … boring stuff

Lean

Development teams use lean principles to eliminate waste by defining the client value and understand what value is, optimize the value stream, such as minimizing working in progress (WIP), making work and progress visible and traceable, reducing handover complexity and breaking down steps to ensure that the flow of the remaining steps run smoothly without interruptions and waiting times. This also includes the introduction of cross-functional teams and the training of employees who are versatile and adaptable.

Measurement

In order to better understand the possibilities of the current system it is helpful to get some things settled. In order to better assess the health of the product, I need well-considered metrics that can give us a starting point for improvement.

In this area we try to collect and analyse data. This can be planning data, product data, quality data or more general team data. It is important to mention that this is always about trust and we plead for the data to be used correctly in the right hands. We do not want to create a surveillance state, we want to get the best out of it for our clients and our product.

Monitoring

As mentioned, Continuous Learning and Improvement should be a key factor in our DevOps culture. A nice saying that I like to use myself is “Continuous Improvement is the only Constant in DevOps”

So what do we want to achieve:

Sharing

Classically, this includes establishing a non-blaming culture, which sounds simple at first glance, but which, as I have learned, is apparently in our nature to reject fault. It requires a lot of experience and understanding and the management should lead by example.

An open communication culture should encourage the ask/share principle. We want to focus on solving difficulties and not on assigning blame. In this sense, it should also be emphasized that it is always about the overall system and not about micro-problems without looking at the other areas.

We can achieve this by focusing on Collective Code Ownership and by putting the team in focus. All in all - “Sharing is caring” and we should always keep this in mind. If we don’t care about the team and the product, why should our clients?

I am eager to hear your opinion and welcome any comments on this topic. So long - stay tuned and healthy!

Leadership