The 3 ways aren’t just for DevOps

If you’re familiar with DevOps, you will probably have heard DevOps enthusiasts talking about “the three ways”. This refers to three very powerful and practical approaches to managing the work of IT departments, particularly within modern business organisations that use IT to conduct every aspect of the business and that rely very heavily on their customer facing IT.

My thanks to Gene Kim for his article The Three Ways: The Principles Underpinning DevOps, which was where I first learned about some of these ideas.

Here is a brief explanation of the three ways in my words…

• Consider end-to-end flow
• Create feedback loops
• Experiment and learn

I believe that these three ways are so powerful that they should be used by anybody involved in IT management, whether or not they take a DevOps approach. I’d go further and suggest that you could apply them wherever you happen to work and whatever you happen to be managing.

The First Way: Consider end-to end flow

When you just focus on the activities you are responsible for, without understanding the entire end-to-end flow of the system you are part of, you can end up making local improvements that actually result in an overall negative effect. This is sometimes described as “local optimisation”, and here’s a simple example of how it can happen.

Let’s suppose your organization requires lots of new laptops. Each laptop has to be purchased, then someone has to install the software, and finally the equipment must be handed over to the user. If the purchasing department optimises their process, so that they get laptops really quickly, then you can end up with a large stockpile of laptops waiting for their software to be installed. The users don’t get their laptops any faster, so the improved purchasing hasn’t helped the end-to-end process. In the meantime, your software installers may be stressed by an increased workload they are not equipped to cope with; you have increased the cost of your inventory; you have an increased risk of many laptops being stolen; and increased the probability that the laptop manufacturer will release a new model that makes your laptops obsolete before you’ve had any use out of them. So the improvements made in purchasing actually result in a reduction in the overall end-to-end service quality.

This very simple example illustrates that what truly matters is understanding, and optimising, the entire end-to-end flow. And this takes us to another key idea – if you want to optimise end-to end flow the work should be pulled rather than pushed. It’s the software installers who need to set the rate at which procurement orders laptops. That way the laptops won’t arrive until the installers are ready for them.

Obviously, in a real IT organization things are more complex than this, with many interrelated activities, but the same ideas still apply. Make sure that you consider end-to-end processes and flow of work whenever you design activities and processes.

You can find a distressing, but sadly not untypical example of a service with no consideration of the end-to-end flow in this description of my visit to the 2012 Olympics with a disabled family member, which ends:

“Clearly some effort was made to provide access for people with mobility problems. Disabled parking was available. Wheelchairs were provided at each location where they might be needed. There was a shuttle bus from the station to the Olympic park. There was a spectator mobility shuttle for transporting people between venues within the park. All that was missing was a joined up plan that would have helped people get from the disabled parking to their seats in the wonderful new athletic stadium.”

The Second Way: Create Feedback Loops.

Many of us get feedback on our services by measuring customer satisfaction. The trouble with this approach is that you only learn about what’s going wrong when it’s far too late to do anything about it. Great feedback arrives fast enough to ensure you can act on it in time to prevent it impacting customers. One example of this is the stop button which forms part of the Toyota Production System. This lets any worker stop the production line if they detect that something is going wrong. The issue can then be resolved before defective parts are passed on to the next part of the process.

You need to build feedback into all your processes to help you detect potential issues as early as possible. One way to do this is to start testing your new releases very early, even if they are not yet completely ready. That way you don’t have to wait until the last minute before you begin working on resolving issues. If you do wait till your release is ready to ship before you start testing, then really significant test failures – which might well have shown up early – can result in long, embarrassing and potentially costly delays.

Another helpful action you can take is to ask for feedback from internal customers, as well as external ones. Think about where you fit in an end-to-end value chain (see The First Way) and identify who might be able to give you the earliest and most helpful feedback.

The Third Way: Experiment and Learn

If you completely understand the system you are part of, then you may be able to design new services, processes or tools and get them exactly right first time. But most of the time, most of us simply don’t have enough knowledge or understanding to do this. We need to experiment.

Experimentation doesn’t mean trying things at random to see if they work. The important thing to understand about experimentation is that you need to think carefully about your problems first, so you can create a good hypothesis about the actions you can take to resolve them; and then you need to make specific predictions about the outputs and outcomes you expect to see when you actually test your hypothesis by trying out the actions you proposed.

You still won’t actually learn what you need to know unless you have excellent feedback loops (see The Second Way). You need to think about these before you start. What data do you need to help you compare the actual outputs and outcomes of your trial with those that you predicted? And how will you collect that data? When you have accurate feedback loops in place you know exactly what happened as a result of your “experiment”, and that means it’s very much easier to plan improvements next time around.

The third way does always involve an element of risk, but the alternative – guess what to do and do it with no feedback loops – is just as risky and is likely to result in even worse outcomes. If you want to build a successful organisation where people feel empowered to experiment and to learn, you need to develop a culture where experimentation is normal expected behaviour; and where it’s taken for granted that everyone applies rigorous measurement, as part of a process of trial and improvement, to ensure they achieve what they set out to do.

You can learn more about experimentation and learning in the ITIL Practitioner Guidance (section 3.2.4.5).

Summary

The three ways of DevOps aren’t just relevant for organizations that have decided to adopt a DevOps approach to IT service management. Every organization can benefit from the discipline of the three ways.

What could you do to apply the three ways to the way you work? Please let me know what you try and how it works out.

Image credit: pfly