Challenging the operational rites

Over time a strange set of rites and rituals grow up around the Require-to-Deploy value stream*. Some of them are there to protect the quality of the output but others have ceased to add value.

Handovers

As we work on DevOps transformation of the value stream, we should begin by looking at all the handovers between functional groups, and one of the first things we should do is to challenge the level of ceremony. These handovers are the most likely points where two classic forms of Lean waste occur: inventory pile-ups, and unnecessary waits.
Most of the rites and rituals accrete around handovers between teams, and these are the first points I map and optimise when looking at the flow in a value stream.

Part of the power of DevOps is to challenge the "level of ceremony" of these, and try to reduce the complexity of handovers. Put simply, DevOps subjects them to a bullshit test.

I'm a great fan of operational handover documents, where a template is provided with all the necessary headings, because this kind of documentation ensures that the project has at least given some thought to every one of the areas of operational capability which we want them to, before handing the system over to operation.

On the other hand these artifacts are only necessary because of the dysfunctional relationship between development and operations, and the artifacts themselves often have little ongoing value after handover. Operational handover documentation is really a band-aid to try to repair the problem addressed by DevOps.

Level of ceremony

It is a good example of the kind of high levels of ceremony which build up over time to try to address shortcomings in handovers in the value stream. Each time something goes wrong, the downstream receiving team introduce new controls in the handover to protect them selves in future. Trust diminishes and ceremony increases.

Such ceremonial "crud" is a good indication of dysfunctional relationships. I'm always reminded of the bizarre rituals which have grown up over time on the India/Pakistan border as the two militaries face each other down and posture.

Is the amount of formality really justified? Are the artifacts produced really necessary?
I had a great example of this recently when I was in a discussion at a client site about ways to automatically generate the release notes to be used by the testing group and the operations teams. It occurred to me to ask why release notes are necessary at all if they are being automatically generated from Jira. Why not give the testing and operations teams direct access to view the information for themselves in Jira as they need to? Or if explanatory documentation is necessary then provide them with their own query or reporting capabilities. Automated report generation is adding little value. The question is still being considered so I am not holding this up specifically as an improvement, but it points to the principle that we are trying to increase levels of collaboration between groups, and formal structures of handover are obstacles to that.

To improve these handover points, we can consider such strategies as

• Simplify the artifacts
• eliminate them altogether
• integrate the communications
• automate the whole handover from one system to another

Theatre

Much of the ceremony is in fact theatre. For example, security theatre or architecture theatre. Groups held accountable for assurance go through their little dance in order to cover their own accountability, when everybody knows that the activity is not in fact improving the quality or integrity of the resulting product. Again we should challenge these rituals which have grown up over time and lost their significance and value.

Simplify

The goal is not to eliminate all ceremony entirely: it is to simplify.

Make it as simple as possible but no simpler. Some definition and formality is required in all handovers to manage risk, and in fact to make them easier by setting clear expectations.

Nor does it help to mash teams together in order to theoretically eliminate the handover.
The whole point of DevOps is to get groups to collaborate across organisational boundaries, so organisational reshuffles do not in fact contribute to DevOps cultural change. Reorganization should be one of the last steps in a cultural transformation, once you fully understand the new ways of working and recognise the implications for the organisational structure.

Therefore we seek simply to understand where the handovers are and to make them as lean as possible.

*This value stream model is IT4IT™ www.opengroup.org/IT4IT

Here is an excellent related article from Rob Spencer "All the rituals but no results ". https://changeandrelease.com/2016/06/26/all-the-rituals-but-no-results-c...