Making agile real – the zen of Continuous Delivery
Sidetracked with the technical specifics and implementation planning, IT teams switching to Continuous Delivery are missing the bigger picture of what CD is all about.
Much of what is written about Continuous Delivery at present seems to revolve around technical challenges and technical choices: “Which is better: Puppet, Chef or Salt?”, “Should I use Jenkins, Go or XL Release?”, “How do I build a CD pipeline with containers?” etc. etc.
If we’re looking at CD properly, though, this is the sideshow – an implementation detail at best. The real CD story is much bigger.
Part 1: Focus on the end user
Having a focus on the end user sounds like an obvious statement that every organisation should claim to aspire to, but given the way we release software today, there is often an enormous gap between the people creating the software and those that actually use it.
This gap, which was reinforced by organisational structures that put lots of layers between developers and users, resulted in something like an “emotional variant” of Conway’s Law: not only did we build systems that reflected the layers of organisation, we developed mentalities and boundaries of empathy to match: “The system is totally unworkable for the users? OK, but look how clean our repository layout is/how elegantly we’ve managed to decouple these components/how complete our test coverage is…”
Every member of the team needs to understand how the overall service they are creating is put together and delivered to the user. They also need to be able to contribute to improving the service if they see opportunity to do so.
If you’re thinking that this sounds suspiciously like “product teams” or “end-to-end teams” you’re on the right track. The key point here, though, is that this goes beyond development, QA and Operations to include the business and, beyond them, the end users for whom the software is actually being built.
Part 2: Improve through data
Most organisations collect information on many aspects of system behaviour. But the majority of this information is of a technical, operational nature: in most enterprises, it’s much, much easier to figure out whether a particular CPU in your data centre is doing OK than understanding whether a particular user of your services is satisfied.
Which of the two pieces of knowledge is more important for your business, however? And if it’s the user that really matters, why then are we basing so many decisions about the user-facing functionality and behaviour of our services on educated guesses.
Improving through data means applying the same methodology that we apply to improving the technical performance of our systems:
- Measure to identify the pain point
- Formulate a hypothesis as to what is causing the pain point
- Make a small change to a single part of the system based on the hypothesis
- Measure to check for the expected improvement
- Rinse and repeat
Enough dreaming already
If you’re thinking that this all sounds nice but won’t happen any time soon, bear in mind: you’re probably working with people in your own organisation that are doing this today. Tell this story to your colleagues in Marketing you’re quite likely to hear that this is all rather old hat.
That, to me, is what Continuous Delivery (and, by extension, Agile) is all about: revolutionising the way we serve our users. Making the delivery of IT services a modern experience. An experience we can be proud of.