Deep Thought: How to build a DevOps planet

In trying to determine the question to the answer “42!”, Magrathea was commissioned to build a brand new supercomputer called “Earth” by the mice. The solution of the question was expected to take 10 million years. Sadly, Earth was destroyed by the Vogons to make way for a hyperspatial express route 5 minutes short of completion. After all that effort, one slight complication resulted in the work being lost.

This is the risk we are trying to avoid when implementing DevOps. The last thing we need is to have gone through all of that cultural and technical change matching the perspectives we spoke of in my last blog on the Total Perspective Vortex of DevOps, only for something to make the whole exercise irrelevant before realising any value or benefit.

The Big Bang may work for the initial creation of a universe, but it doesn’t work when implementing DevOps into our Enterprise. Again, we must look carefully at the question from the Intro blog of “How do we implement DevOps into our organisation?” and understand it more fully. Now we realise from The Total Perspective Vortex blog that there are different perspectives, we must also now realise that there are differing values. The value of continuous build and integration, for example, is different according to each perspective.

Let us go back to our three example roles from the last blog, The Developer, The Incident Manager and the CIO. The value each derives from automating the build of systems into a test environment is viewed differently. For the Developer, it is the quicker determination of quality of code by applying coding standards to the system at time of build. For the Incident Manager, it is the rapid time to market for the correction of user issues. For the CIO, it is a reduction in cost overhead for the building of IT systems. Each views the value delivered in terms of quality, time and cost, but each applies a differing weighting.

Our goals in implementing a DevOps environment must always be to ensure that we are delivering value and quality to the enterprise to provide the greatest return on investment possible, in the shortest possible time. Once again, quality, cost and time.

So a useful framework is to consider the following carefully;

• Break down the DevOps structure & culture into smaller bitesize chunks, just as we do with any Agile delivery, as your organisation views it today.
• For each of our chunks, consider the perspectives of the key stakeholders, maybe your top 3
• For each stakeholder, apply the value that each perspective gains in terms of cost, quality and time, using a scoring mechanism, maybe like planning poker.
• Total up the values for each chunk, whilst retaining the breakdown by perspective
• Create a backlog list of the chunks and prioritise according to total values
• Concentrate on implementing from the top of the backlog list, that is, the highest value, or greatest return on investment

Oh, but, hang on a minute! What if someone decides to build a hyperspatial express route through our DevOps planet? Well, firstly, if we have all of our perspectives considered, we should know that the planning charts and demolition orders will have been on display in our local planning department in Alpha Centauri for the last 50 years. In other words, if the Entire Enterprise, our universe, is collaborating, there should be no surprises. It means we should also be able to adjust our perspectives and our values and so impact assess our backlog. As perspectives and values change, so what we must implement for DevOps, and the priority in which we do it. Thus, we always implement whatever provides the greatest return on our investment. In practical terms, add another bullet point of;

• Over time, hold a retrospective to consider how your organisations perspectives of DevOps have changed and adjust the backlog accordingly

Of course, in doing all of the above, never forget a key DevOps principle – CALMS. Culture, Automate, Lean, Measurement & Sharing. In other words, consider the impact of the culture change, automate what you can, ensure that processes are lean to provide maximum value, measure your baseline and your new vision and quantify your improvement, and finally, always ensure you share and communicate what you are doing and what the results were. This is a topic we will deal with in greater detail at a later date.

Although the mice did not achieve their end goal, many others did. The human race got to stick around for a bit and fjords were invented. In building your DevOps planet, remember well that it is not just about achieving the end goal, it is also about the journey, and that journey should reveal value at every step you take, the maximum value you can provide. But just what is that value? What are the benefits we are supposed to get from this? Ah yes, our third question. That is on for next week I think.