We recently sat down with Jez Humble, Founder and CTO at DevOps Research and Assessment, DevOps thought leader, and author of some of the foundational books on delivering software at scale. Jez and his co-authors Nicole Forsgren and Gene Kim just recently published their latest book, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Read on to learn about the book Jez says predicts DevOps culture in the 60s, why cynicism on teams is a sign of burnout, and how to drive change slowly through organizations.
Tell me about Accelerate. Why did you write this book?
Jez Humble: For the last four years, Gene Kim, Nicole Forsgren, and myself have co-produced the State of DevOps Report with Puppet (this year we’re doing it with Google). We’d been figuring out how to measure high performance in technology teams, and what the factors are that predict high performance. A lot of people said, “you know, it would be really nice to get all of this in one place, and for you to explain why I should believe this and why it’s not just some industry bullshit.”
So we had been thinking we should write a book, and then Martin Fowler met Nicole at a conference and told her if she didn’t, he was going to. And Nicole said, “oh, hell no!” So we sat down and wrote it.
Accelerate covers everything from the technical practices of continuous delivery, through to culture, product management, people management, and leadership. And it talks about what’s important, what’s not, and how to predict IT performance, software delivery performance, measuring those things in a meaningful way, and ultimately, how they impact organizational performance.
DevOps and DevOps culture are something people have been talking about for a few years now. Where do you think we are on the adoption curve for these ideas?
Jez: It’s a great question, and it’s one that frankly, frustrates me. One of the books I’ve got on my bookshelf is called The Human Side of Enterprise, by a guy called McGregor and written in 1960.
McGregor talks about these two (really poorly named) theories of management, Theory X and Theory Y.
Theory X says, you treat people in a carrot-and-stick way. Theory Y says, you assume people want to do their best work, and provide an environment that encourages that.
McGregor says that managers get what they believe. So, if you believe that carrot and stick is necessary, and that people fundamentally aren’t interested in their work, then people will behave that way. Whereas, if you believe that people fundamentally want to do their best, and you treat them that way, they will behave as such.
So this is not a new idea, but 70 year later, how far are we along that adoption curve, you know? So this isn’t a new problem that we’re solving for.
Frankly, being in the kind of late-capitalist paradigm that we find ourselves isn’t very conducive to that kind of transformation. So, I think DevOps is a new iteration of that.
That being said, we have some new models and new data that show that culture impacts performance, and that new ways of doing things impact software delivery. So we hope the data will help to impact adoption, but it’s incredibly hard.
It’s very hard to change, and the way our economy and organizations are structured fight movement in this direction.
It’s interesting because ultimately what we’re talking about is building a happier, more productive workplace, but sometimes that gets boiled down into bringing in a new tool, or bringing in a DevOps team, which will all of a sudden deliver us this digital transformation thing.
Jez: Right, and it’s very tempting to think that if you change something tangible like a tool, or rename a team, that you will achieve the result.
It doesn’t work that way, though. You also have to change the way people work.
This is very difficult to do. How do you balance the pressure to deliver the work at hand while also focusing on, “well, how do we actually get better?” Or, “How do we invest?”
And the irony of that is, it’s by investing and getting better that you actually are able to accomplish your work faster. I mean, that’s one of the reasons it’s called Accelerate, is because doing the hard work of improving the way you do things will actually make you better at doing the things. But the fact that you’re so bad at doing the things is what makes people say, “Oh, we don’t have time for this, we don’t have capacity for this.”
So, it’s a classic catch-22.
Our target audience are the folks who say, “we don’t have time to fix this system, we just have to work with what we have.” To convince them, we use data, and arguments, and diagrams, and conciseness.
Do you think speed is a good argument for changing your process? I’m wondering if that can bite teams, that if they say they need to reevaluate their systems and that doing so will allow them to go faster, that then they will be responsible for more work than they were before. “Great, you can move faster? Then we’ll give you more tickets.” Is it a double-edged sword?
Jez: Yeah, that’s interesting, the idea that your punishment for doing better would be more work. And I think it’s very easy to be cynical. And interestingly, from a research point of view, being cynical is one of the signs of burnout. And burnout is one of the things that we actually measure in Accelerate, and we talk about the things that can impact burnout, and some of those things are practices, and some of those things are effects of leadership.
And I think that all of these discussions have to be framed within actually a quite humanistic context of what we’re all trying to achieve. And this is the job of leaders, to say, “Well, here’s the vision, here’s what we want to do,” not just in terms of how we want to sell our customers, but also in terms of the kind of organization we want to build.
And I think if you fear that doing better at your job will lead either to you being fired because there’s no need for you anymore, or for you to experience negative consequences as a result, that’s a real issue. That’s happened. It’s one of the jobs of leadership to make sure that people don’t actually fear these outcomes because that’s an excellent way to ensure that nothing ever gets better.
Are there things in the book that you found surprising? You’ve been embedded in this research for years, but were there any aha moments that caught you anew?
Jez: I’m an early adopter of lean software ideas, and a lot of this stuff that we’ve talked about isn’t necessarily new. I want to emphasize that if you know a lot about this, you’re not going to read the book and have your whole world turned upside down. But there are definitely some things that I didn’t have sort of, “Ah-ha,” moments, so much as I had, “Yes!” moments, where I said, “I knew it!” And we see that in the data.
For example, things like showing that high performers achieve higher levels of throughput and stability. I bang on about this a lot because it’s still the case today that people think that if you’re going to go faster, you create less stable, low quality systems. But lean software is all about the idea that there is not actually a trade-off here. Going faster enables high quality and high levels of stability, and it’s really nice to see that in the data.
Also, seeing that high performance in IT actually impacts the business, that’s really great. Seeing that a lot of the practices that we’ve been talking about for years actually, measurably, significantly impact performance, that’s really great. Some of my personal soapboxes are continuous integration and trunk-based development, and it’s very clear in the data that these practices have a significant impact on performance. So, lots of good news.
Are there any practical tips for teams hoping to implement these changes?
Jez: Well, to start, leadership enables the implementation of practices, both lean management, product management, software delivery practices, things like CI. Those, in turn, impact delivery outcomes, they impact cultural outcomes, like job satisfaction and reduced burnout. Software delivery performance impacts organizational performance.
People may ask, “can I do this without leadership support?” And the answer is, you can, but making it stick and making it spread throughout the organization is extremely hard without leadership support. Leadership support matters, it really makes the difference.
But good leadership on it’s own isn’t enough either. You have to do the hard work. There’s an interesting bit of data from 2016, which I think reinforces that. When we see the shift from low performance to medium performance, everything gets better except change fail rate, which actually goes up for the medium performers. And, again, the data doesn’t tell us why that’s happening, but our hypothesis is that what’s happening is, people are trying to do the same stuff faster, without doing the hard work of actually making the organizational process changes.
So you just have to do the hard work. There’s no replacement for process improvement, and I would emphasize that in addition to leadership.
How can organizations make this change a priority?
Jez: At some point, you have to be able to say no to people. That’s very important. In any successful organization, there will never be a lack of work to do, and someone, probably middle management, has to be able to say, “Listen, we’re going to dedicate some capacity to doing improvement work, and that’s going to mean that we’re not dedicating 100% of our capacity to building features, and that’s okay.” So, being able to say no to people, and then being able to also drive alignment across at least part of the organization in terms of defining the goals and making sure that everyone is pushing in the same direction. I think that those two things are pretty important.
One of the things that we’ve been hearing from folks who are successful in driving change is that they kind of hide it at the beginning. So, they’ll say, “There’s nothing to see here, I’m experimenting,” and then they’ll get their one little team moving, and then add folks, until they have created some momentum. And then, they can go and say, “Look at what the results have been.”
Jez: Yeah, I think that’s absolutely right. I would particularly contrast that with another common way of doing things that is very risky, which is the top-down, “We’re going to change the whole organization at once.” And that often fails. And I think this piece around, “Let’s try it over here and make a bunch of mistakes and get it on the rails, and then try to spread through the rest of the organization.” That’s exactly right, and it mirrors just the psychology of how organizations work. In every organization, there are a bunch of people who want to try the new, shiny thing. There are a bunch of people at the other end, who won’t change how they work, come hell or high water. And there’s kind of a curve in between of people who are more or less change averse.
And you can’t change a whole organization at once. You have to find the people, who have the capability and interest in trying new stuff and get them successful, and then move out in exactly the way you’ve described.
I heard you used CircleCI to write Accelerate. Can you tell me a bit about that?
Jez: So, I very strongly believe in what some people call dogfooding, but I don’t actually like dog food, so I call it drinking my own champagne.
If I’m going to tell people to do something, I want to make sure that I’m practicing it myself. Obviously, I’ve been doing continuous integration since 2004/2005 when I was at Thoughtworks, and in fact, the first book that I wrote, Continuous Delivery, we had a little continuous integration server where we used the Ruby version of CruiseControl so that every time we made a change we built a PDF so that we could see a) that our document was valid and b) to have something we could download and read through to proof what we’re writing.
And so we did that again this time. And the technology was slightly different, so we used GitHub to keep our book in, we were using markdown as our format. And we used CircleCI for the continuous integration.
The idea is that every chapter was a file in markdown, and every time we made a change to one of those files, we would commit it to GitHub, CircleCI would pick it up and create a webpage with the whole book in HTML format, and a PDF version so that we always have the latest version. And so, you know, if we have reviewers or other people we want to show it to, we can just point them there. We published the HTML to an S3 Bucket on Amazon, so you could just go to the webpage and always see what the latest version is. So, I mean, very simple stuff, but it’s a great way to always know where you are and share that with other people in a very low-friction way.
I first started using CircleCI in 2016 when I was working for the US federal government. I have strong opinions about tools, and there’s a lot I like about CircleCI. It’s very easy to get started, and that’s why we picked it. And we use CircleCI at DORA. We have a platform that we operate, and we use CircleCI to build and test and deploy that platform. I certainly only have good things to say about it.
Any parting words about why people should read the book, or who they should give it to?
Jez: The idea is really for this to be something that anyone will find interesting. And the feedback has been that it’s a nice, short book. It’s clear. If you’re an expert in Agile, you might not find anything particularly new, but what you will get is a very strong sense of validation, that actually, here’s a scientific approach demonstrating that the stuff you’ve been talking about, how it works and why it works and how it connects to everything else in this space. So, I think it is a book for everyone.
Ultimately, what we want to do is make the things that reflect the way people do things. Because that’s what research has shown is what’s effective. We want to make it normal. Ideally, we want to make it so that people read this and say, “Well yes, obviously everyone does this. What are you talking about?” And no one needs it anymore. Our work would be done.
