Finding Out What Works Before Making "Big Bets"

Duncan Lawie, Enterprise Architect - DBaaS Architecture and DevOps, Credit Suisse

Duncan Lawie, Enterprise Architect - DBaaS Architecture and DevOps, Credit Suisse

Approaching 25 years in IT and 20 in the Financial Services Industry, I was confident of the direction the industry was going. So when the term DevOps started gaining traction, I thought it was just another one of those fads that consultants want to force upon the world. But over the last couple of years, I’ve fallen a little bit in love with DevOps. Which might seem a bit strange when I can’t tell you exactly what it is. Perhaps the mystery is part of the attraction. The delight is that DevOps talks about things that matter and asks us to treat our work in IT as a subject for study and an opportunity for improvement.

"Happy staff are more likely to bring new ideas to their work; happy customers are more likely to recommend a service to others"

Indeed, my favourite definition of DevOps at the moment comes from Jon Smart, formerly of Barclays Bank and now at Deloitte – “Better Value, Sooner, Safer, Happier.” Notice that this definition doesn’t talk about technology at all. Instead it focuses on outcomes. What do we want from our technology? Value. What is valuable in software will differ from person to person, role to role, and business to business. If you are building self-driving cars, then safety and reliability are going to be top of the list. If you are running a social care organisation, then compassion and fair outcomes are likely to be key values. And if you are in the depths of infrastructure operations, then reducing toil certainly deserves a place on the list.

Most of the other aspects – faster delivery, with higher quality, whilst maintaining or improving software security – are things that every IT organisation is likely to strive for, regardless of industry. Accelerate by Nicole Forsgren PhD, Jez Humble and Gene Kim, describes how adopting DevOps practices actually delivers these changes. One of the most surprising aspects of the research is that delivering change faster is strongly correlated with both a reduction in change failure rate and an improvement in time to recover when things do go wrong. This seems to be true whether the primary problem is due to change itself or as a result of some other kind of issue in the system. This is primarily due to DevOps approaches creating environments designed for change.

My favourite metaphor for stability occurred to me on my morning commute. A train in a station is perfectly stable – but it doesn’t get very far. That same train can still be stable whilst accelerating and at high speed, because the track is built for it. The problem comes if you don’t have a track, or the wheels don’t fit well. Organisations which aren’t used to change need to put a lot of work into the track-building; getting used to making change a regular part of the life of a technology, rather than an intermittent, poorly managed pain. In the meantime, they are in for a bumpy ride when they try to move – and may be disheartened and stop, rather than understanding contributing factors and starting to solve them.

This spirit of enquiry is a key point of DevOps. Find out what works before making “big bets”. This means coming up with a possible innovation or improvement, taking a view on the benefits it would offer and then testing that hypothesis before leaping in. For example, when we add a new service to a platform, we ask customers what they want, create something interesting and test it out. Do they use it? What bits do they like most? What do they want next? If they don’t use it, then it won’t have a future at all – and we have the delight of stopping development in that area before we have gone too far.

There was one more word in Jon Smart’s definition - “happier”. This is something we tend not to think about as a technology goal. The term DevOps started from the simple idea of putting Development and Operations teams together. Why does that matter? Because much of the IT industry had entered a world where Dev had a goal of change – new features, more shiny – whilst Ops had the goal of stability, and a fear that change was the major enemy. With a common goal – a balance of change and stability – the Devs and the Ops can work together towards shared success. They really do find themselves happier, rather than at odds.

Perhaps happiness seems a little fluffy. Some might be more comfortable if we talk in terms of customer or staff retention – things we can see as affecting the bottom line. Still, in the end, happier staff and customers is a great way to improve those characteristics. And not just those. Happy staff are more likely to bring new ideas to their work; happy customers are more likely to recommend a service to others.

All of these things can be measured. If we have a mature DevOps system, we can make small changes, measure the effect of those changes on time, cost, quality, happiness, and then work out whether we are heading in the right direction. Rather than guessing in the dark, we can step into the light, experiment and move forward – delivering business value.