Beyond DevOps Infinity

This model only had a cameo appearance in my latest book Reflections on IT Paradigmology so I wrote this article to give it a more prominent role.

The DevOps infinity loop is a popular and effective way to illustrate the continuous flow of work through software development and IT operations. It may have been AppDynamics’ Dustin Whittle who created the first version in 2013 but there are now several legitimate variations with slightly different steps. In all of the versions, however, the steps focus on technology, with an implicit understanding that these activities are somehow or other related to the user organization that needs the solution and benefits from it.

In order to see the bigger picture – DevOps’ context – I often depict a prequel and a sequel to DevOps. The prequel is the recognition of a need for improvement, resulting in requirements for the development of a solution. The sequel is about benefits realisation: effective use of the functionality and information. The prequel and sequel are non-trivial: it is pointless to deliver a product and service for which there is no business case, and for people who do not use the product and service effectively. There is also a parallel domain in which – often oblivious to the software developers – the user organization is preparing for and undergoing change to their way of working.

This is why I created an extended version of the DevOps infinity loop. The standard technology-oriented DevOps infinity loop is shown in red, while the blue benefits-oriented loop illustrates the activities related to the user organization and its needs. Although each loop is distinct, there is implicit interaction between the loops to keep the activities aligned. For the sake of simplicity and aesthetics, each loop comprises eight activities that are more or less in sync with each other.

I assume that the technology-oriented steps plan, code, build, test, release, deploy, operate and monitor need no explanation. The benefits loop comprises eight steps: specify, communicate, organize, train, prepare, launch, use and evaluate. Two of these steps – specify and use – are more densely packed than the others and are described in more detail than the other steps. DevOps focuses on the fast flow of work, and it is important that work flows through the user organization at the same rate, to keep things in sync.

The benefits loop

While it is tempting to start with specify, I prefer to start with use because it represents the heartbeat of the organisation: business operations. There are also initiatives that start from business strategy with the existential question: how do we differ from our competitors? But most of the time, we reflect on current performance and how it could be improved. So, let’s start with use.

Use is about the application of technology to do things more efficiently or effectively, or to do different things because technology makes it possible. It is about getting the return on investment in technology. It entails:

• Using the service and the underlying product’s functionality 
• Interpreting the data and discovering the information (which I define as data that is useful in the given context)
• Using this information to make better decisions (this is the function of information: to reduce uncertainty)
• Acting on those decisions, in the realisation that if nobody acts on decisions that have been improved by information derived from the underlying information system, no value is realised.

It is often the case that users struggle with knowing what functionality is available and how to use it, using the functionality and using it well, and understanding the meaning and value of the data. A crucial question to consider, is who is responsible for effective use. Is, for example, the product owner ‘done’ when the product has been launched and is available for use, or does their concern extend into ‘product usership’? Is there a benefits owner as well as a product owner? Is there a super user who is tasked with proactive support? Use is often the weakest link in the chain.

Use runs in parallel with operate. It is where value is co-created between provider and consumer by means of service: the application of resources by each party with and for the benefit of the other party.

Evaluate concerns itself with assessing whether the expected outcomes are being realised, and whether the expected outcomes are still the most appropriate ones. Each improvement is based on a hypothesis, and these hypotheses are assessed. On the left-hand side of the model, an improvement is hypothesized and on the right-hand side, the hypothesis is proved or disproved. Evaluate runs in parallel with monitor.

Specify comprises three parts:

• Hypothesizing that an investment opportunity will achieve the desired results (it is difficult to know what will work, and the hypothesis is the basis for experimentation)
• Formulating the requirements
• Specifying the functionality and service that will fulfil the requirements

Some specifications are input for coding, while other specifications are used as a starting point for changes to the user organisation.

Engage is about making sure that stakeholders who have not yet been involved in the proposed improvements, know what is going to happen, and – crucially – why.

Organize represents whatever organizational changes are needed in terms of goals, roles and responsibilities, activities etc.

Train ensures that people are equipped to use the new ‘tools’ and possibly to also work in a different way.

Prepare concerns itself with making sure that everything needed is in place, and that people know how to transfer from the old way of working to the new way of working.

The set of steps from specify to prepare runs in parallel with the plan-deploy DevOps steps, but the individual steps are not necessarily in sync with each other.

Launch is the actual transfer from old to new, in parallel with deployment, and with sufficient support on hand to ensure continuity during the transition period.