Interview with Jez Humble on DevOps culture at GOTO Chicago 2014

Hi, it’s Mike with UGtastic. I’m here at GOTO Conf 2014. I ‘m sitting here with Jez Humble, who today presented on DevOps, and he’s got a background as the co-author of the Continuous Delivery book, and he also was working on another book that we’ll get into in a minute, but also, and also, and also, you’re a busy person. He’s working on a new conference called FlowCon, but first, you know, thank you for taking the time to speak with me. Thanks for having me. Your talk today was on DevOps. Can you tell us a little bit more about what part of DevOps and what does, DevOps is one of those terms that means a lot of things to different people. You helped write the book on Continuous Delivery, which helped lead into kind of what we call DevOps. Can you tell us a little bit about what that means to you, and how that relates to your talk today? Yeah, so, I mean, which is a very big question, and debate rages on how to define DevOps and what DevOps really is, but for me, ultimately, DevOps is about creating a culture in which we’re always learning how to get better at creating, and evolving, and operating great products and services. With a particular focus on… …collaboration between all the different people involved in doing that, whether that’s the engineers, the UX people, the operations people, and all the various groups who are involved in doing that. So it isn’t just about deploying. It’s about the whole application cycle, from code writing to delivery. Yeah, and, you know, even outside that cycle, I mean, the point of Continuous Delivery is to give you this capability to be able to get changes out fast to users in a low-risk way, and to make it… …economic to work in small batches, but once you have that capability, the question then becomes, “What do you do with it?” And I think, you know, the people in the DevOps field will tell you that you use that for creating a feedback loop so that you can make sure that you ‘re working on the right things, so that you’re building things that actually delight users and improve the customer experience. And so it kind of feeds into that whole discussion around building things that are delightful and better serve our customers. Right, and is that what your goal of your talk was today? Actually, what was the title of the talk? The title of the talk… It was a long one. It was. You have a lot of very long titles. I do, yeah. Sorry about that. So, yeah, “DevOps: Culture and Practices to Create Flow.” “DevOps: Culture and Practices to Create Flow,” and flow being… Flow being being able to get ideas out to users as quickly as possible, so I mean, the question of the thing that is actually doing the flowing was kind of the premise for the talk, right? Because I go back to the Toyota production system, and the idea of flow in the context of the Toyota production system is the customer puts in an order, “I want this car. How fast can you get it to them?” Right. So there’s this kind of idealized concept of one-piece flow of being able to go from customer order all the way through to delivering the vehicle as a single piece of flow with no kind of interruptions and cues or anything like that, which is unachievable, but the idea is that you’re always moving towards that. And so the idea is, what’s the equivalent of that in the context of software development? And so my contention is that what you should be looking at is check-ins, creating builds, and trying to get those builds out to users as fast and as safely as possible. And how do you actually do that? Okay. And some people, that is, even at the very beginning of how to write software is a controversial topic right now with TDD. Right. You know, is TDD that? Right. It’s not how to write software, much less how to finally get something to that end-user. Is that something you’ve been experienced or having conversations about, like trying to figure out those kind of things with your teams? Yeah. Absolutely. I mean, one of the things that, again, I said in the talk and I also say in the book and to anyone who’ll listen to me, frankly, is that you’ve got to build quality into the product. So the idea that you can somehow write some code and then there’s like quality activity a bit further down where you find out if it’s any good, that doesn’t work, or you have like a separate quality team. It’s the responsibility of the people building the software to build quality in. And one of the ways that you do that is through TDD, by making sure the developers are responsible for writing the tests that show that their software does what users want and what they expect of it. I mean, TDD is a whole other topic in its own right, and you know, one of the things for me about TDD is, you know, going back to the idea of satisfying the user, what we do in TDD is we put ourselves, it forces us to put ourselves in the perspective of the user of the software. Right. The first thing you do when you write a test is, you know, when you’re starting TDD for a new module or component or class or function, you think about what’s the API? Because you have to write the test against an API that doesn’t exist yet. Right. So you’re designing the API which puts you in the perspective of the user. Yeah. And that for me is a really important part of TDD, it forces developers to think as a consumer of the software they’re about to build. Right. And design an API that’s simple to use and simple to test. Yeah, you get that pain early that, like, whoa, what comes here? Right. And actually, once you’ve worked out the right test to write, actually writing the code that implements that should be relatively easy. The hard bit is working out what the test should look like. Right. And so that, I think, actually is very, you know, there’s a very lean aspect of that. And just, you know, jumping straight over into, you alluded to a book that you’re working on. Is that also in the same vein of topic or is this, what is the book? So, the book is called Lean Enterprise, and the book is about how large companies can innovate at scale. Okay. And so, excuse me, pardon me, the problem that we have with the continuous delivery book is we talk about the technical practices and the principles behind them, but organizations have trouble implementing it. And we see it time and time again, people say, “Oh, we’d love to do this, but we can’t because of, oh, excuse me again, we can’t because of our architecture or because of governance or because of compliance or because of our budgeting process.” And so, the book tries to address the whole ecosystem of innovation. How do you build and grow a company that can innovate at scale? You know, big companies who don’t treat IT as a competitive advantage find it very hard. I mean, IT ends up being a critical path. Right. There’s no investment in it. It’s treated as an, you know, an order to- A cost center. Yeah, a cost center, an order-taking function. And then, you know, it takes ages to get anything done because it has to follow all these rules. Imagine if your software actually was a competitive advantage to your business, how would you do things differently? And of course, there are companies who do do that, you know , Netflix and Google and all these other kinds of companies that are doing this stuff at scale actually treat software as part of their product development process. And it’s central to how they innovate and it’s kind of exploring how enterprises can adopt that culture. And I can see how some of this, all of these things can be daunting for somebody who’s adopting them because even these terms, lean, flow, now I’m forgetting the other one, but they have multiple meanings in different contexts, like when you described flow, my first earlier, when you described flow. I was thinking about developer flow and then you’re talking about product flow and it’s, is it been something that’s been a challenge making sure that people understand these terms that have been used in different contexts, that they understand the context of what you’re talking about? Yeah, I mean, it’s a huge problem, even understanding the concepts and understanding the names and then understanding how they fit together and, you know, people make basic mistakes with this. You know, again, it’s not because they’re stupid, it’s because it’s genuinely difficult and counterintuitive. And a lot of people think that lean is about cutting costs. Lean is not about cutting costs. Lean is about reducing waste and by reducing waste, we end up with lower costs, but you don’t just go about looking for expensive things and cut them out of the budget. Right, right. But people do that. People are like, well, we’re going to go lean. That means we’re going to reduce our head count and we’ll actually know that’s not the case. And again, if you look at Toyota, I mean, in Japanese culture until quite recently, everybody had a job for life, so you could never fire anyone. So the idea with lean was that you would increase productivity by, you know, making people more efficient at what they did and more effective at what they did. And that frees up people to work on higher value things instead. And what they would do is they would use the efficiency gains they got through applying the principles to drive the growth of the company. Because those people who were doing all this low level stuff are now freed up to do high level stuff. And now we can do more stuff. And so that means we can expand our market or introduce new products, you know, it gives you the power to do all these additional things. Whereas a lot of people adopting lean, they think it’s about, you know, making people redundant and firing them so we can reduce costs. Right. No, absolutely not. That’s totally not the point. But you know, this is just one of many misconceptions and it’s very counterintuitive. And it’s, and it’s even, this is a word that has come up in a lot of interviews is empathy. You know, trying to put your mind into the listener’s mind. And, and that’s, that’s always a trick, you know, here we ‘re doing these interviews is trying to, to take what are my own biases, like when I hear lean, I’m a developer. So I’m thinking, I mean, I’ll flow, I’m thinking developer flow. So when you’re, when you’re at these presentations, do you often get people that are, or when you’re talking these topics, do you often get people surprised or pushed back or expecting something different and, and have to be brought back into the fold or. Yeah. I mean, a lot of the time, I mean, because, you know, people come up and they, you know, they expect me also to be a continuous delivery guy. We need to be talking about these very technical things. And I found that the technical stuff is not the problem. The problem is leadership and culture. And so I tend to talk about those things these days. And, you know, I’ve been doing a bunch of research in my book. So what comes out in my talks is basically a lot of the research I’ve been doing from the book and, and, and talking about that stuff. And that’s not what people often expect to talk about. Um, but in my experience is the most important stuff. So yeah, I mean, I kind of hope that people will come and be excited by some of this stuff and be inspired. I mean, the most I can hope is that people come away with a bunch of ideas for things they can try out. That’s what I really hope, but you know, people are not necessarily going to get what they come for. Um, and, uh, yeah, so one of the things I want to do is say , sorry to the people that didn’t get what they were expecting out in the talks. Maybe they got something that they can use. What do they say? You didn’t get what you asked for, but you got what you needed. Right. Hopefully, hopefully. Well, and then just to, to segue straight into your conference that you’re working on, um, FlowConf, it’s obviously something that’s related to this topic, but what is it? Where is it? Okay. So this year it’s, uh, the week of Labor Day, uh, 3rd of September and 4th of September in San Francisco. Uh, you go to flowcon.org, flowcon.org and, uh, my fabulous British accent. Okay. With a W. Yes. F-L-O-W-C-O-N.org. Um, and the idea of the conference is to explore the whole range of stuff that goes into building great products and services. So we talk about UX, we talk about product development, we talk about, you know, deep dive on technical topics, talk about culture and we talk about all those things. And the idea is to emphasize the fact, A, that it’s a cross -functional activity. So, you know, we don’t have a developer track and a UX track. And, uh, abstract, because that kind of goes against the whole principle, which is that we all have to work together and we explore all the different aspects that go into creating great products. Yeah. The developers need to know more about the business, business or the needs and empathy, have more empathy with what the business needs and the business needs to understand what they’re asking. So everybody needs to kind of get empathy. Yeah, exactly. No, and that’s absolutely right, I mean, my personal experience, I, I wanted to design a conference that reflects our industry as I want it to look, not as it looks right now. And I also kind of wanted to think about, you know, what makes a great conference. When I go to a conference, I often will attend topics that I don’t know very much about so that I can just get my mind blown. Right. Um, I really enjoy that experience. So I kind of wanted to go to a conference where you could see a bunch of things that were related to what you do, but not directly related, so tangentially related and get an idea of how all this stuff fits together to create a bigger picture, because again, one of the things that I lean is, you know, you can’t just optimize your particular part. You’ve got to think about the whole and think about the high-level objectives of what you’re doing. So, you know, it’s important to think about all these other things and how they fit together and as you say, create empathy for all those different people and what they’re trying to do. So the conference is focused on that and on real stories of people doing real things, um, in difficult situations. September 3rd and 4th, San Francisco, flocon.org. Yeah, and if you register before May the 30th, there’s an early bird, so you get it cheap. Great. Thank you so much for taking the time to speak with me. Pleasure. Thanks so much for having me. Thanks. User groups with lots to say, interviews and more. No way! Sharing great ideas in the tech community, fascinating conversations, a plethora of information, find out for yourself today at ucdastic.com. Thank you.