CALMS - A Holistic View Of Work

Clemens Scholz — Tue, 31 Dec 2019 15:05:55 +0000

CALMS

Ever since hearing about CALMS the first time it is stuck in my head.

But first let's talk about how brutally misleading this acronym is. We are talking about changing the way of working and not even of the single individual, but of all the parts that make up a company. This is a revolution, who can keep calm in a revolution? Well okay to be fair this term is "just" a description of trends and ongoing processes, so it is not as near as dramatic as a real revolution. Except if you work in company which is still stuck on working the waterfall way, then you should be ready for quite a ride.

The term is not exactly new, CALMS was coined in 2010, first as CAMS by Damon Edwards and John Willis at the Devopsdays in Mountain View on June 25. Later that year in a talk Jez Humble added the L, sadly the slides of this are now inaccessible. Some folks perceive CALMS as a framework with the potential to supersede ITIL and ITSM, in my opinion they will much rather be adapted to the changing needs.

So what are the wondrous meanings of these five letters? Lets dig in!

C - is for Culture

This is the part with the revolution. A lot has changed since industrialization has changed society. It is time for society to turn the tables and change the ways that companies work into a more life affirming manner. The funny part is, that the companies will end up with higher motivated employees with improved problem solving skills and overall better productivity rates. Work does not have to be dull, boring and repetitive. But let's turn down the scope a bit, we are not talking about the culture of societies here but rather about the organizational culture. The agile movement already has shaken the foundations and proven that at least for teams the waterfall system is ripe for retirement. With DevOps and CALMS on the rise the old management methods are fighting a losing battle. Companies which do not embrace that change will face rough times and their chances for survival are slimming.

A - Automate me baby

The most prominent part of DevOps is the automation. In IT it is not as feared as in other industries. While in manufacturing many jobs have been replaced by machines, this is not so for the software industry. A very important part of the DevOps mission is to spread the A through the C. There are very many reservations against automation, deeply ingrained in the minds of the colleagues of other departments. In a future article I will talk more about automation, but for now let me state: if you already believe why it is great, collect the negative ideas of your colleagues and then prove them wrong! If you don't believe in automation, then I challenge you to back up your reservations by facts and check if they are hard enough to survive scrutiny.

For me automation is the key to increase performance and life quality for me and my colleagues. I love it when a small change reduces overhead, improves robustness and brings a smile to the team mates faces.

L - Lean

This concept has quite a history. Since 1948 Toyota actively developed TPS yet only in 1992 they delivered a first publication about it. But already in 1990 the term Lean was invented, at that time it was only used for production. As the challenges in development are very different, already Toyota invented the Lean product development to improve the situation in these areas. Now all of this is manufacturing related, so why is it relevant for the IT area or the DevOps idea? Simply because the Agile Movement is based on lean methods. The most modern way of organizing development teams stems from there, so thank you Toyota.

There even is an institute solely dedicated to spreading the lean concepts - check out https://www.lean.org/WhoWeAre/.

If you search for lean in books at Amazon you will have over 10 000 hits, too much to even look them all up. So these ideas and concepts are pretty popular and if you are not familiar with them, you should consider taking some time to discover more about them. I can guarantee you will find something which will help in your daily work.

M - Measure All The Things

Simple no? Just measure and monitor everything. Ha! Of course it is not so easy. First of all, to introduce logging will create technical overhead and requires storage for the data you want to keep. Also the data has to be evaluated in some way, so you will have to have people or software to do that for you. So only collecting will already cost something and evaluating will cost even more. Why not just do nothing and wait until a customer reports a problem? Besides that using your customers as product testers will cost more trust than is affordable, having no data to trace a problem will result in huge costs to find the failures.

With this you already have reasoning why to at least log as much data as you can afford to, but there is also the legal side. Many employers love to log data about their employees. This causes a continuous debate about workplace privacy. And just recently in Europe there were the new GDPR regulations introduced, which greatly affect how customer data may be collected and used. So after all it is a very complicated matter, but if done right it is very rewarding.

S - To Share Is to Care

Since the rise of the open source software movement the idea to share knowledge becomes ever more popular. Companies which take the risky step to open up their sources to a community reap in the rewards if done right. The company I work for increased their license sales, since taking this step and many bugs and security issues are being reported by the community, even huge improvements are being provided.

Or take a look at the history of Wikipedia itself, which is freely sharing all existing information.

The natural enemy of sharing on the other hand is the Intellectual Property, of course finding the best balance between the possibility to profit from ideas and free access to knowledge is difficult.

But this is the large scale, take a look on your own workplace. Maybe you could profit from sharing your knowledge and ideas? Do you really want to be a knowledge silo? Well I do not and the more the colleagues know of my duties the calmer I can sleep.

*****

So, looking at these five letters you might realize, that the topics included encompass every aspect of work. And this is my reason for dubbing it as holistic view. Do you disagree? Let me know about it and get in touch :-)

“Hello, nice to meet you.”

Clemens Scholz — Thu, 28 Nov 2019 17:22:10 +0000

“Hello, nice to meet you.”

Seemingly insignificant words, but coupled with a charming smile and a firm handshake they will make a good first impression to someone you meet for the first time.

Do the exact same thing with, let’s say a police officer, which just has stopped you for a control. It will at least be super weird if it does not get you into trouble.

This is just one of a myriad of examples about why communication is circumstantial.

So why the tag DevOps?

Because communication with people is a key element of solving the complex problems we are facing each day. And adapting a DevOps mindset will demand even more communication than the agile movement already did.

Back when I started my IT career coders were mostly introverts, or in a more ugly term “basement dwellers”. This has changed a lot in the last two decades. Still, from my experience, there are some common misconceptions that IT people have about communication.

1) Emotions are distracting, facts are sacred.

Life would be so easy if a fact would always hold the same value. But the truth is that the mood of someone presenting something is extremely important. Maybe that person is distracted, because of a very bad event and as a result is even giving false statements. Or a cocky junior developer challenges a disgruntled senior, who in turn will use condescending language, diluting the truth of the statements. In any knowledge transfer of any sorts you have to really understand the involved emotions, if you want to get to the essence of the facts.

2) Truth is obvious.

The best way to present data is just the numbers, without any explanation. Any person intelligent enough to understand the data should always arrive at the same conclusions. (Sarcasm off) A scientific research paper would only consist of the results section, if it would be this easy. Of course there will be an abstract, an introduction, a methodology description, a discussion and a conclusion section. If not even more parts. You have to consider the possible audience which will receive the data and adapt the presentation of the data accordingly.

3) Manipulation is evil.

While being ethically correct, this mindset is extremely dangerous. Technically every word in a communication is controlling how the recipient will receive the information. So it is extremely complicated to present something in a true neutral manner. To be aware how to manipulate people is rewarding in multiple ways. For one you can spot more easily when people try to manipulate you, also you will understand how you are influencing others. With this knowledge you can more easily force people to look at the facts from different sides. Yes it sounds weird, but you can manipulate people into making more informed decisions. Isn’t it marvelous?

In my opinion it is part of the DevOps objective to strengthen the soft skills and the emotional intelligence. Through this we can create better functioning teams, increase inter-departmental information flow and reach company wide situation awareness.

DEV Community: Clemens Scholz

CALMS - A Holistic View Of Work

“Hello, nice to meet you.”