DevOps or Die?
In July Hubert Tardieu wrote in his post Journey to 2018: Surfing the B2B Tsunami that:
“As the 3rd Digital Revolution ensues, organizations can no longer ignore the warning signs, we estimate that businesses have around two years to prepare, adapting their core processes and culture to thrive in a world of Digitalization.”
And for many businesses, to survive in a Digital world, building a strong DevOps capability will be vital: it really is time to adopt DevOps or die.
But what do we really mean by Digitalization? I recently saw an excellent presentation by Norbert Luetke-Entrup (Head of Technology and Innovation Management, Corporate Technology at Siemens) which he delivered at the 20th meeting of the Atos Scientific Community earlier this year. In it he addressed the question of what is Digitalization and answered it by saying that it is like game of football. Except the pitch is oval shaped instead of rectangular. And there are 4 goals instead of one. And there are six balls. And sometimes spectators run on to the pitch and start playing too. And no one knows the rules or how to keep score. The only certainty is that to stand a chance of winning, you have to be in the game.
So what gives you the best chance of winning a game like that? I think part of the answer can be found in The Cynefin Framework which was developed by David Snowden. It has its roots in complexity science and suggests that the way a problem should be tackled depends on the relationship that exists between cause and effect in the problem domain.
For problems in the obvious domain (like password resets) the relationship is clear and the outcome from a given course of action can be predicted easily. For problems in the complicated domain some analysis may be required to figure out the best way to proceed but the relationship between cause and effect is still predictable (and this is typically the domain where traditional projects work well).
However for problems in the complex domain the relationship between cause and effect is only apparent in retrospect. Liz Keogh has illustrated this domain with a great example:
“Ludicorp produced a game called Neverending (a big multiplayer online game). To get more people to come and play this game they setup a site where people could share screenshots of the game. And people came and they shared screenshots of the game. And Ludicorp thought that’s brilliant, people will see the screenshots and they will come and play the game. But people also shared their holiday snaps and photos of their families and kittens. And that became Flickr. That was how Flickr was created: it was originally a multiplayer online game. You couldn’t possibly have predicted it.”
As Norbert’s football analogy clearly articulates, when we are tackling the challenges of Digitalization we are operating within an unpredictable complex problem domain. So having used the Cynefin Framework to categorise Digitalization as a complex challenge, what advice does it give for how to be successful in this context? David Snowden puts it this way here:
“Our decision model here is probe-sense-respond: we conduct safe-fail experiments, we don’t do fail-safe design.”
In other words, the key to success in this domain is to do something, check if it generates a desirable outcome and then, if it does, do more of it and, if it doesn’t, try something else. Note that the value of The Cynefin Framework here is that it helps us to categorise Digitalization as complex. The suggested approach to take in this context is actually very similar to other existing paradigms such as Plan-Do-Check-Act (from Lean Thinking) and Build-Measure-Learn (from Lean Startup). Implicit in using any of these approaches is that the time and cost for each experiment cycle must be kept low to minimise the risk (thus keeping the experiments safe-fail).
This is one thing that Agile software development hoped to enable by shortening the lead time from initial concept through to the delivery of working software. In fact the first principle of the Agile Manifesto published back in 2001 said this (my emphasis):
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Unfortunately, for many organisations, their attempt to move towards Agile software development has actually resulted in what Forrester refers to as water-Scrum-fall: up-front requirements specification and planning followed by incremental software development followed by a big test phase and delivery into production at the end. In his article for the Software Development Times Dave West notes that frequent releases of software are necessary for rapid feedback but observes that many organisations struggle to achieve this in practice:
“Frequent software releases to the customer enable rapid feedback and ensure that valuable software is being used as early as possible. However, most organizations do not have the architecture required to support dynamic, flexible releases; instead, they do infrequent releases backed by heavy processes and governance.”
And this is why DevOps has a key role to play. DevOps is realising the original Agile ambition of “continuous delivery of valuable software”. DevOps is enabling the rapid-feedback safe-fail experiments that are necessary to be successful in complex environments. DevOps is one of the essential ingredients for survival in the game of football that is Digitalization. And any organisation wishing to surf the B2B tsunami successfully will need to embark on an enterprise-wide roll-out DevOps practices or face the very real possibility of extinction.
Picture: Copyright Siemens - Used with permission