Automation is not DevOps

Nor is any technology or product.

I should remind a famous quote:
?The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.?
Bill Gates

It may sound counterproductive from an Automation specialist to reveal the limitations of his job, but I have seen a wide range of inefficiencies, and many failed attempt to fix them.

To be clear from the outset, I do think technology and automation are a mandatory milestone in a company?s DevOps journey, but they are no more than tools or enabler to achieve something bigger: help delivering the business value people expect when you mention that term: DevOps.

If you?re familiar with the?CALMS model, you know that Automation is only one of the 5 pillars for DevOps.
The others, Culture, Lean, Metrics and Sharing are equally important, and a good reminder that it?s not only about technology. The problem with those is that it?s a bit harder to action them directly, it requires some knowledge, analysis, thinking and? iterations!

Culture:

Sum of ideas, attitudes, and social behaviour of people is what makes a company-wide (the system) performance possible, transcending the archaic way of managing performance by isolating highly specialist fields, and optimizing their production on their relatively narrow field of expertise. This is the model inherited from mass production industries, for economy of scale. Doing so disconnect the work of individuals or so called ?teams? from the actual business value it is intended for, hence leaves each team fighting for their short sighted KPIs relative to their field, without true and sincere collaboration. How many times have I heard techies saying sales people from their company are selling inappropriate solutions that they, ops., will have to support. It?s a standard outcome when revenue making team is fighting against the team that tries to limit the opex, their KPIs are working against each other, and the resulting culture gets in the way of collaboration and continuous improvement. And if it?s not the sales department, it could be any business department, asking for yet another new complex software to be supported before the rollout of the previous one is complete, and technical debt paid off?
In such environment, your co-workers are your first enemies to your performance, that?s why changing job might look so attractive, current competitors to your company are not really working against you, as much as your own colleagues do.
In such system, evaluating individual or team performance is the cherry on the cake, a futile exercise because the individual is evolving in an inefficient system. As Dr Deming said: ?All anyone asks for is a chance to work with pride.?

Lean:

The simplified idea is to focus strictly on value added effort, in small batches, instead of managing teams with a busy-o-meter approach. The goal and metric should be the value provided to the business, eliminating waste, and measuring the actual value. Activities and tasks should be disciplined so that they are done just in time, just enough, an evolve with the needs. This goes far beyond the technology, it requires the business to have processes that allow for value accounting, measurements where technology can be used to gather, track and report on that data. To enable this the batch size should be sufficiently small to avoid the effort to value relation to be untestable for a long period.
It is wasteful to engage in long and complex projects because ?we know? we have a list of specifications that we?ll need to be addressed at some point, and to deliver the solution in a few months or years. Even if something is seen as best practice in the industry, that a big feature needs to be implemented now in its entirety, in your context.
Instead we should identify the value the business needs now, to respond to it as quickly and efficiently as possible, no need to add extra-nice feature for the sake of it. For sure the initial specs won?t be what was actually needed, but if you accept it from the outset and work to refine those requirements as you build the product, you are sure you are not spending time in features that won?t be needed. That does not mean you don?t plan ahead, the key is to prioritise those value, have a development process that allow estimating and planning delivery in an accurate but not necessarily precise way, and that every choice you make support future evolution and changes.
By the communication and collaboration required in that feedback loop, and through the obsession of business value you will eliminate waste. After all, are you more efficient towards achieving business value by working 4 weeks uninterrupted, or by identifying waste worth 4 weeks? of effort during a long meeting with the business, and together realize there might be priorities that have been overlooked?

Measurement (or Metrics):

The key here is not tracking all and every metrics, most of them won?t be tracking the actual progress made (they are Vanity metrics as explained in The Lean Startup). Tracking time spent on project per individual will not relate to value provided to the business if that project produce an undefined amount of waste. How do you evaluate project A to project B in terms of business value? Chances are that they?re both seen as critical and need to be done yesterday. This lack of value management, or probably lack of clear communication, vehicle down the hierarchy that everything is important or, with time, equally unimportant. Battling on every front may seem productive because the teams gets extremely busy, but the time required for task switching, and the corners cut to deliver something lead to poor quality and a constant need to firefight and coming back to fix what the business assumes is already achieved, and no longer on the radar.
That?s usually why focusing on quality as a first measure will provide great benefits in the medium to long term, it?s a way to stop the accumulation of technical debt, reducing the firefighting, freeing time for other activities.
But don?t be fooled, the debt accumulated to this point is a drag that will still slow you down until it?s paid off, and need to be managed on a daily basis, not left on its own. Identifying and avoiding choices that will create that debt, will pay off in the medium to long run, company-wide. But individuals disconnected from rest of the business, won?t see the debt creating choices, as it may not be their responsibilities, and evaluated on their KPIs, when it becomes a problem to the business. This is where the wall between Dev and Ops is created: a feature or product may be released by the Dev team, but a technical debt, such as documentation, may mean the Ops team will have to pay it off, with much more effort it would have been needed to avoid it from the start.

Sharing:

Finally, this one is not be the most obvious, but should not be overlooked. I?d suggest having a read at Steve Thair?s post, from DevOpsGuys (@TheOpsMgr):?Is the S (sharing) in CALMS redundant.
Many people discover their own assumptions either when attempting to express their point of view, or by listening to others?. It is good practice to make sure that sharing is not only a by-product of the culture, but also a mechanism and an effort to ensures that the improvement loop is closed, so that?such activities can?feedback into the culture by promoting, facilitating and sharing the knowledge in improvements attempts: aka.?validated learning.
The other benefit of sharing, is to amplify and spread principles and practices internally and externally, giving a broader source for innovation and improvement. After all, to truly benefit from a DevOps mindset, the whole organization needs to embrace it, from the technology teams, to the other departments and the customers. By sharing your journey, you give your co-workers the insights of your efforts, allowing them to engage at the right time for their own benefits, and yours?

The first Way of DevOps:

Back to the ?3 ways underpinning DevOps?, as exposed by Gene Kim in ?The Phoenix Project: A Novel About IT, DevOps, and Helping Your business Win?, many discussions on the subject have?ablated a big chunk, right at the start.

In?the 1st Way: Systems Thinking, there is this famous picture in the Phoenix Project With Dev and Ops linked by an arrow. I believe, many people only have this picture in mind when explaining DevOps, and did not remember, let alone?read, the accompanying text explaining the ideas behind.

This is not just between your Dev and Ops team on a technical level, this represents Systems Thinking, which does?require the creation of?a delivery System across all business value streams to improve.

Dr W. Edwards Deming?s work,?The System of Profound Knowledge?is?a management philosophy grounded in systems theory?which goes in great details in the concepts that DevOps leverages and are illustrated by the?picture.

Automation is only the (mandatory) enabler so that we, techies, can take our eyes off the screens, to go talk to people and understand the system we evolve in, understand the values of the business, engage, and start contributing pro-actively. When IT start looking less busy, and engage with the rest of the business to create value, the IT department of your organization will look less like a cost centre for?opex, and more like an innovation enabler. The key is that innovation needs a delivery system, your conveyor belt, to ship value.

Takeaways:

Automation is only a fraction?of the DevOps picture. Working towards automation is a mandatory milestone with its own challenges and where choice of technology and technique of implementation are some of the keys to success. But the real value-add work starts when you engage with the business to participate in that whole system.

Remember to make an effort to not simply ?do as you?re told?, but to connect your effort with?your organization desired value creation, and show that you?re ready to collaborate.