Making Agile Real: The Zen of Continuous Delivery
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.
Don’t get me wrong: as a technical kind of person, I can get very enthusiastic about the tech: there are a lot of cool tools and frameworks out there and the tooling landscape is expanding rapidly. Working with evolving technology is a lot of fun, and there are plenty of challenges to be solved around supporting Continuous Delivery at scale…which is why we develop XL Release, XL Deploy and XL TestView.
The fact that we now have a set of tools to automatically build and deploy applications, provision environments, run tests and more is not what I think is important about CD, however. Even the notion of wiring all these tools up efficiently to create delivery pipelines isn’t all that interesting. To me, the thing that is really exciting about Continuous Delivery is that it can allow us to fundamentally change the way we interact with our users. I think CD can finally allow us to turn software delivery into something approaching a modern consumer experience.
In short, Continuous Delivery isn’t a toolset, and it isn’t a business process either. Continuous Delivery is a new way of doing business.
What does this “new way of doing business” look like? What is the mindset, or the culture of a Continuous Delivery organization? To me, these are the most important aspects: focus on the end user and improve through data.
Part 1: Focus on the end user
Having a focus on the end user sounds like an obvious statement that every organization 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. I’ve worked on numerous teams where we never really knew who was actually going to use the software, or why. We certainly didn’t have any personal contact with the end users of our software, and thus little ability to empathize with their needs and constraints, or put ourselves into their shoes to try to understand how the system could best work for them.
This gap, which was reinforced by organizational 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 organization, 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…”
If your team knows your users, if you have some kind of personal connection with them, if you meet them from time to time for a chat, to talk about software, but also baseball, or family, or your next vacation, or whatever…you cannot feel proud of a system that is totally unworkable for them.
It’s not just enough to create an emotional connection, however. In order to turn the intrinsic motivation into great software and a great user experience, 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 an opportunity to do so — whether in “their patch” or area of expertise or outside of it.
If you’re thinking that this sounds suspiciously like “product teams” or “end-to-end teams” or “Devops,” you’re very much 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. And the aim of giving everyone visibility over the entire process, and the ability to influence it, is not because more pairs of eyes can spot more opportunities for optimization: it’s because a more engaged team that has a greater influence on the delivered service and a stronger connection to the end user is more motivated to look for improvements in the first place.
Part 2: Improve through data
If we have a team that is motivated to continuously make things better for our end users, how do we identify where the opportunities for improvement are in the first place? If we have given them the chance to make changes, how do we figure out whether those changes are helping? In a word: data, data and more data.
It’s not as though we don’t have any data today, of course. Most organizations collect tons of information on many, many aspects of system behaviour. But the vast 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 center 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 of decisions about the user-facing functionality and behaviour of our services on educated guesses and gut feel, without any kind of follow-up plan to figure out whether we guessed right?
Improving through data means applying the same methodology to making services better for our users 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…
…see the full post at xebialabs.com
