Chances are if you’re an engineer or product manager who works on anything even somewhat related to continuous delivery, Jez Humble wrote your handbook. Literally. This co-author of the Jolt award-winning Continuous Delivery also made hefty contributions to both Lean Enterprise and The DevOps Handbook.
And if his list of publications weren’t impressive enough, Jez Humble’s Linkedin profile is sure to inspire similar feelings of inadequacy and awe as few, like Jez, have had such an opportunity to shape the growth of the software delivery industry.
Whether it was building and scaling ThoughtWorks Studios’ continuous integration and release management platform Go, or helping Federal agencies to deploy to cloud services safely, or helping high performing teams move faster and build more secure, resilient systems at DevOps Research and Assessment, LLC — (Excuse me while I catch my breath), Jez has not only shaped the products that are used within the software industry, but the way that those teams build the products themselves.
I sat down with this self-proclaimed loud mouth to discuss his keynote at DECISIONS 2018, and Jez kindly agreed to do a brief Q&A so we could pick his brain on the state of things in the world of software delivery.
I’ll admit that I was a bit intimidated going into this interview. (Hello? Did you see all the accolades I listed?) But lucky for me, his professional achievements are matched by his humor and charm. He’s the kind of guy who puts you immediately at ease, and by the drop of his first swear word, I knew we’d get along just fine.
I wish I’d thought to hit record before we got going because Jez was sharing his wisdom right out of the gate. I won’t ruin the surprise of what Jez will be presenting on October 2nd in San Francisco, but I can say this — He’s constantly surprised by how much we’re still talking about the concepts we started exploring back in 2010. People he encounters will often say, “Hey, have you heard of this lean product development?” Or, “We do this thing called Agile. Have you heard of it?” And Jez’s response to that is, “It’s all the same! These are all the same idea, just calling it something different. The idea is constant — Not fucking it up.”
I share this because it comes back around near the end of our interview.
Kimbre: I went back, and I found some of your older interviews to see how far we’ve come. One question that kept coming up was “Is Continuous Delivery just a theory or are people doing it?” And I’m curious what you think now, so many years later. Do you feel like we’ve finally come to a place where it’s common practice? Or do you feel like you were saying earlier, that people still aren’t quite gotten putting them into practice?
Jez: What’s happened is that everyone says they’re doing it now because they know they kind of have to in order to be taken seriously. That’s a nice place to be. In 2010, when the book came out, people thought it was very interesting, but it was crazy. You could only do it if you worked for a certain kind of company, you know, some unicorn. I think now everyone feels like, well we really should be working in this way.
But then, on the other hand, I talk to a lot of companies. Some companies are saying, “We are using this new way of software development called ‘Agile.'” Just now? It’s 2018!
So we’re in this position where people feel they ought to be doing continuous delivery, but are people actually doing it? In my experience no. I think that it’s very patchy. I have a friend Mike Roberts who I used to work with when I was at ThoughtWorks, and he says “Continuous is much more often than you think.” And I think that applies very much to this.
I have a test for continuous delivery, which is, “Could I, at any point in time, press a button, and take what’s in version control and ship it, with a mojito in my hand?” That’s my continuous delivery mojito test. A lot of people don’t pass that. A lot of people are still doing releases evenings and weekends. And while they might have automated it, and while they might be doing it more often than they used to, this idea that at any time in the day I can press a button and push to prod whatever’s in trunk right now, I don’t think there are actually that many places that could put their hands on their heart and say they’re doing that. I don’t think so.
Kimbre: So for the companies who are not doing that, that can’t pass the mojito test, what do you think is the barrier for them? What is getting in the way of them implementing continuous delivery as it’s designed?
Jez: There’s a couple of barriers. One is architecture. We talked about microservices and service-oriented architectures. I think a lot of times, typically in big companies, you’ve got hundreds or thousands of systems and they’re all tightly connected to each other. You have to push out these big orchestrated releases where you’ve got to change this thing, then you’ve got to make a change over here, and then you go to push a database change, and then you’ve got to roll this system forward, etc. And this idea that you should be able to push a single service — make a change and push it out without impacting the rest of the environment? That’s still very hard to do in a lot of places.
So people sometimes ask me, “How should I do orchestrated releases?” And my answer is, “You shouldn’t.” If you have a real service-oriented architecture, and certainly a microservice architecture, you shouldn’t need to do these very complex, orchestrated releases. So architecture is a big constraint.
The other major constraint is culture. A lot of organizations still have this very risk-averse culture where they don’t want to try new things. There are organizational silos. People fear a loss of control; they fear doing things in a different way. There’s a lot of “This is the way we’ve always done it.”
I’m interested to hear the extent to which you see those things as barriers to adoption of your tool.
Kimbre: Ironically, these actually speak to the benefits of using our tool. In terms of architecture, Split can be used as a phased release mechanism to helping people get through that barrier. One of our case studies talks about how we helped WePay migrate to microservices so that they could do releases in the way that they wanted to. They knew what needed to happen, but were unable to do so previously because of the way things were architected. So they use Split’s product to enable them to reliably, and more quickly migrate to microservices so that they could change their development process.
Being able to run experiments on our platform also helps with culture. When you can share experiment results across a team, and democratize that data, everyone feels connected to where the product is headed, and why. That helps with the culture aspect.
So, for companies who can’t pass your mojito test what are some of the benefits of continuous delivery that you’d want to remind them of?
Jez: I mean there are so many, which I think is why it’s such a big deal today. The reason that Dave and I wrote the book back in 2010 was that we just didn’t want to spend our weekends in data centers doing releases anymore. We thought it was a shitty way to spend our time. And it was miserable for everyone. We actually want to enjoy our weekends. It was really about making releases reliable and boring.
But there are many other benefits as well. By doing the things that you need to achieve that, which is a lot of automation work, a lot of simplification work, and a lot of improvement work. That improves the quality of the software.
It also reduces the ongoing cost of evolving your software because what you’re fundamentally doing is reducing the transaction cost of pushing changes. So you can put changes out more often, at a lower cost.
It allows you to make more effective product management decisions. If you’re pushing out six months worth of stuff at one time, it’s very difficult to see which of those changes moves the bar in terms of delivering value to your customers and your organization. Whereas if you’re pushing things out in a much more fine-grained way, you can then start to reason about which feature actually did deliver the value. This is exactly the kind of thing you talked about with Split, being able to attach particular value to particular features through analytics.
The final thing I think is important, is that it makes your employees and your customers much happier. If your customers can get the things they want more quickly, that makes them happy. Sometimes I see this thing happen when someone mentions continuous delivery. Someone will say, “Well our customers don’t want changes all the time.” And my response to that is, “Why are you delivering them changes that they don’t want? Why don’t you try delivering things they do want instead?”
The other thing is that it makes your employees happier. I used to work on projects where I’d roll off a year before it even went live. That’s because it took a year to get anything delivered. That’s really miserable.
If you can have an idea, code up a prototype, push it to production to a small subset of users, get some feedback, and iterate? That’s really great. As an engineer to actually have that connection to users makes them happier. I think that that’s the other piece.
Kimbre: So you mentioned a couple different kinds of improvement. Improvement suggests that there needs to be a measurement component to qualify something as an improvement, and quantify by how much. Are you starting to see an evolution of layering measurement on top of the delivery process itself?
Jez: In Accelerate, the book I wrote with Dr. Nicole Forsgren and Gene Kim, we actually found a way to measure software delivery performance in a valid and reliable way. We measure that in terms of throughput metrics — which is lead time, tracking the release deployment frequency — and then some stability metrics — time to restore service and change fail rate. We’ve got an interesting extension of that model this year. I can’t talk about it yet, but it is coming out at the end of this month so by the time DECISIONS happens I’ll be able to talk about it.
So, we found a valid and reliable way to measure how well you’re doing in terms of your release, your delivery, your software delivery process. So that’s one piece.
The other piece is, “Is the software I’m building actually delivering value to users?” That’s where the stuff that you’re talking about comes in. Building analytics into your software platform so that you can find out which features people are using, what they’re deriving value from, and then, which of those features that people will pay for, and are delivering value to your organization. That’s the other piece.
Those are the two metrics pieces. Number one, “How effectively are we able to deliver stable, reliable software?” Number two, “To what extent is that software delivering value to our customers and hence to our organization?”
Kimbre: You also mentioned that it also has an impact on employees. That suggests that this could be impacting the way that teams collaborate. How does continuous delivery change how about teams work?
Jez: A really interesting question. It requires a lot more collaboration between different parts of the value stream. It’s challenging to do continuous delivery when ops are sitting in one silo, test is sitting in another silo, and development is in a third silo. I’m not here to say that it’s impossible, but I can tell you that it’s very hard. You have to have much better collaboration between the different functions.
That, or you need to architect for it. That’s what we see with the advent of cloud. Where cloud is done well, you’re able to see platforms where developers can self-service deployments to a production environment. There’s a nice clean separation of responsibilities between the platform and the apps that features are deployed to. Each one is treated as a product in its own right, and you’ve got cross-functional teams building and evolving that platform as a product. Then developers can just self-service builds, releases, and the metrics that they need to get from that product.
We’re moving away from this model where it’s all very process-driven and process heavy, where to get anything done, you’ve got to send a ticket for this team to do something, and then they create tickets with yet another team.
We’re moving toward much better collaboration and architecting for delivery. Delivery is a capability in its own right. Traditionally architecture has been about things like performance, security and cost as the central capabilities. Now we’re talking about testability and deployability as architectural characteristics in their own right, and you’ve got to architect for those.
Kimbre: So staying on the idea of teams, I know you work at DORA with a lot of different companies from a lot of different verticals. Can you talk about maybe some of the common challenges you’re seeing that teams are facing?
Jez: The answer to that is going to be the same as the answer I gave you before which is architecture and culture. Well, that’s not always what we get, every team is different. In our assessment product, we measure 24 different capabilities, and everyone is different. We see all kinds of interesting things that tend to be the constraint.
But if you ask, “Why can’t we do this? What is the constraint?” If you work backwards, you often end up at architecture or culture.
Kimbre: So given those challenges, how are teams making decisions?
Jez: I think, quite badly in many cases. If you look at how organizations are run, there hasn’t been very much change in the last 50 years. I’ve got a book on my bookshelf called “The Human Sides of Enterprise” by Douglas McGregor, which was published in 1960 about Theory X and Theory Y models of management.
Theory X is carrot and stick. People are fundamentally lazy and dumb and you’ve got to motivate them by giving them rewards. Theory Y is people want to do the best job and you just need to tell them “Here’s where you want to get to” and then let them self-organise. Your job as a manager is to help enable them. We were very far from being there. I’ve worked at very small, two-person startups, all the way up to the Federal government. I’ve worked at both ends of the spectrum. It is very common still for people doing the work to be order taking. They know their part of the process very well, but they don’t know how the other parts of the organization work. They definitely can’t tie what they’re doing now up to high level strategic goals concerning what their company is trying to achieve this quarter or this year.
Organizations struggle with that, and executives really struggle with that. Executives like to tell people what to do and to get it done, rather than to paint a picture of where you want to go and let teams work out how they’re going to get there. That’s still very, very rare. It’s not that the tools don’t exist. It’s just that they’re tough to implement.
Kimbre: This is my last question, Jez. So get prepared to give a fantastic answer. What is the next disruptive trend in software development? I know, you never get asked this question.
Split Colleague: He’s going to say Agile.
Kimbre: It’s going be the next one. I know it. 2018’s the year!
Jez: (laughs) I mean I don’t know what it’s going to be called yet. But it is, “Not fucking it up.”
Kimbre: On that note. Thank you, Jez.
Jez will be speaking on October 2nd at the JW Marriott in San Francisco as a part of DECISIONS 2018 — an industry-first summit that brings together Engineers, Product Managers, and Data Scientists in a single forum to share ideas on the nexus of continuous delivery, data-driven experimentation, and qualitative user feedback to build amazing products one decision at a time. Use promo code Kim-SC18 for $249 discounted tickets — courtesy of moi.
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.