Brian Dawson - DevOps in 2017

Andre Pino: You’re listening to DevOps Radio, the podcast series that dives into what it takes to successfully develop, deliver and deploy software in today’s ever-changing business environment. This show is sponsored by CloudBees, the enterprise Jenkins company and continuous delivery leader. Today I’m joined by Brian Dawson, DevOps evangelist at CloudBees. Now, Brian and I know each other pretty well and I can tell everyone listening that Brian has a very strong background in DevOps and most of that background comes from first-hand experience. Brian, I’m really excited to have you on DevOps Radio today. Welcome.

Brian Dawson: Thank you, Andre. I’m excited to be here.

Andre: So Brian, for everyone listening so they understand the context of your background and so forth, perhaps you can talk a little bit about your background. How did you come to specialize in DevOps?

Brian: Well, I first start by saying it was fairly organically although I do kind of feel like from the start of my career, it was pointing in this direction. So I’d say I’m a programmer at heart. I had been programming for a hobby since I was a teenager. And then I started in my professional career as a developer in the game space. And software development in the game development industry especially at that time, in the mid-90s, was a perfect example of the tension between a demanding expectation for innovation, i.e. you always had to release the newest features, you were always developing something you hadn’t developed before. But you also had fixed delivery timelines and at that time, pretty much all game development studios followed manual legacy waterfall development processes where we’d crunch, crunch, crunch, crunch and then at the end of the delivery timeline, that fixed timeline, you would throw it over the wall. There was another unique aspect of game development that influenced my career and my focus on DevOps and that’s that game development studios and organizations were heavily siloed due to the focus on technical creativity and the belief in the participants that they needed to have freedom to do things the way that they needed to do it as opposed to standardizing. So while in that space, in recognition of those conditions, across a number of rules was always focused on optimizing software delivery, be it on the technical playing via analyzing and optimizing graphic pipelines or access to a CD. Or shared libraries. Or launching a tools and middleware program so we can increase productivity. Coming out of the game industry, I later moved into positions where I helped organizations implement agile and continuous integration at a time when we weren’t really talking CD and DevOps. Eventually continuous delivery rolled in and then that consulting experience along with functioning in multiple domains QA development and development management gave me a pretty valuable cross functional perspective that just naturally played into the DevOps movement. And that’s where I sort of found my home.

Andre: Yeah, I think that’s awesome because having experience in each of those stages of what’s known today as a delivery pipeline gives you great understanding of the challenges associated with each one of them both from a process standpoint as well as from an individual skills standpoint.

Brian: Agreed. And you know what, Andre? I would chime in on that that a key sort of tenant of DevOps as a culture is empathy and when you are able to work, sort of put on each person’s hat and work from those different perspectives, it’s much easier to have empathy for the stakeholders and the software delivery lifecycle that’s really required for successfully implementing DevOps.

Andre: Yeah. Well, speaking of empathy, in your role as an evangelist, I know that you get to go and speak at a lot of conferences, meet a lot of folks who are in the trenches either doing DevOps or attempting to transition to a DevOps culture and approach. From your perspective, how would you evaluate the current state of DevOps today in November 2016?

Brian: You know, what I would say is that we spent some time in an inception phase. That was sort of lead on by a visionary phase or idealization phase. And I’d say that now we are in the realization phase of DevOps. And what I mean by that is its adoption is not only growing rapidly, it is truly digging in and taking hold and becoming the way that we develop software. To that end, I like to consider DevOps really common sense development, right? We have a name for it. But really what it is about is pragmatically identifying and implementing common sense development practices and breaking away from the baggage of legacy approaches from the days of punch card, tape and compact disc when mistakes were much more costly to recover from. And in response to that, software development incorporated practices that don’t necessarily align with the common sense and the realities of today’s market and today’s development. So based on this realization phase that we are in, I’d say that what I saw with 2016 is a serious growth on the focus of DevOps as a true enterprise need and a true enterprise solution and no longer just the domain of small teams or the domain of the cool kids. But again, really how we do things. And I think you also asked, Andre, if I heard correctly, what are some of the challenges that that resulted in? And what I find is that we are sort of hitting a chasm. We’re taking process and practices that were established at small-scale, defining sort of a happy path for small organizations and technologies which led themselves to the components of DevOps, right? Automation, continuous delivery. And now we have the challenge to say how do I truly scale that across my organization with the vast differences in culture, technology and the silos that just tend to naturally exist in large organizations?

Andre: So let me stop you there and ask this. So as you look at that realization phase taking place, I think what you mean by that is this is becoming a true trend in IT organizations across the board. Do you see the smaller organizations more readily adopting DevOps? Do you see it happening more readily in larger organizations? Where do you see the realization really taking foothold?

Brian: So I see the realization taking foothold in larger, more mature organizations.

Andre: Wow, that’s really interesting. That is really interesting.

Brian: Yeah. And what I mean by that, again, is to say we lived in this idealistic phase where we started to prove this out. And that often happened in smaller organizations or isolated teams within organizations where you were starting greenfield, right? And you could establish cross functional collaboration. You could bring in the appropriate tools and technologies to support automation from the jump. Now the realization of that ideal phase is what is required as part of scaling this into the enterprise.

Andre: So Brian, one of the things that I know that you’ve been doing some great work in is helping organizations understand where they might be in this realization phase. Where they might be in their DevOps maturity. Can you talk a little bit about the work you have been doing there?

Brian: Yeah, absolutely. I’m pretty excited about the reception that we received around what we are terming the CloudBees Four Qs or Four Quadrants of CD and DevOps maturity. And some background on that is what it is is it is a simplified model for describing, defining and ultimately driving your journey to DevOps maturity. It acknowledges the fact that it really requires a focus on what I’ve been calling the DevOps Trinity and that is people in culture, process and practices, tools and technologies, all of which are key components in successfully achieving DevOps maturity. Moreover, it also focuses on the idea that DevOps is really holistic. There’s a misconception sometimes that if I deploy infrastructure as code, I’ve automated my deployments. I’m DevOps. I’ve gone from one point in Dev to one point in Operations. But really DevOps is transformational. It needs to be treated sort of with consideration for the entire organization and I like to term it and say we’re not just going from Dev to Ops, where actually going from concept to customer. Now, what I found in the field is that often times what presents forward progress on the DevOps journey is one, as I said, misunderstanding of what definitions are. Misalignment on what problems they are trying to solve but then moreover, getting caught up in the details. Are we DevSecOps? Are we doing TDD? What’s our code coverage in TDD? Are we Scrum? And often times it helps to pull out of those details, take a simplified view and not say we want to achieve DevOps or we want to achieve TDD but rather have a framework that allows you to say where are we today? What do we do well? What do we need to improve on? And then gain alignment on where were going, i.e. shared objectives, and then, you are able to define a path and progressively get into levels of detail. So the quadrants, if I may continue, basically divide an organizations DevOps maturity into a four-quadrant problem space that allows you to identify where an organization is and where they need to get. So for instance, you could have a quadrant one company. This is often your organization that practices water- Scrum-fall. They may have some CI that dropped in at team level. Some teams may practice scrum or some lean project planning and execution. But they haven’t figured out how to cross the chasm from sort of those team level agile practices to downstream agile practices in terms of delivery of that software. So now, do we have some automated testing? Do we have continuous flow and continuity from our development build out to production?

Andre: So let me ask you this. So certainly, the path to DevOps is not a one-size-fits-all for organizations. So how do the quadrants that you described in your model, how do they help someone to understand what their path might be?

Brian: I’m glad you made that statement, Andre because a focus of a simplified maturity model is that it is pragmatic, not dogmatic. It can be applied subjectively. So I’d say what it allows you to do is it gives you simple, high level definitions that describe four different levels of maturity and based on your goals and objectives, allow you to map your teams and organizations into those spaces and not in a rigid way that says like a CMMI maturity model for instance. We must do X, we must do Y, we must do Z, which, to a certain extent flies in the face of the agile principles that underpin DevOps.

Andre: So why don’t you take our audience through, at a high level, what each of the quadrants are and what the characteristics of each quadrant are?

Brian: Absolutely. So we would start with quadrant one and this we term as team level agile. Characteristics of an organization that – well, let me back up a bit. Let me first describe, because we don’t have the benefit of a visual, that if we look at the axes of the four quadrants, the X axes defines common steps in the software development lifecycle going from the left where we represent upstream development which includes define, plan, code, build. To the right representing downstream delivery of software which represents integrate, test, release, deploy and operate. So if we talk about the name and description of some of the characteristics of a quadrant one company, we are looking at the lower left-hand quadrant and we are focusing on team level agile where we’ve implemented agile, upstream development practices. We have some level of team level CI implementation. We potentially have one or a few teams practicing scrum or other interactive methodologies. However, we have disconnected development and delivery tools and we don’t have shared or common practices across multiple teams. Now, if we move over to the left, where we start to focus on the downstream delivery, we arrive at what we would call a quadrant two organization. A quadrant two organization is termed as practicing team level CD. So one to a few teams have connected upstream and downstream, extended from continuous integration into the delivery process such that they have integrated development and delivery tools, they have at least one off alignment with operations on those fast delivery cycles. However, what they are missing is that they haven’t scaled and codified those processes across multiple teams so they are the standard way of doing things. We can then go to quadrant three where most organizations are today. And this is enterprise agile. And what you’ll see here is you’ll see the organizations that over the past 10 to 20 years have focused on adoption of practices like scrum and extreme programming. And they’ve gained some business alignment with specification. And they have shared project planning and execution across their teams, however, they can only get to build in fast, interactive cycles. They haven’t fully connected the upstream and downstream agile practices. And then we get to where we want to be, where as a matter of fact, roughly only 10% of organizations are today. And that’s what we are practicing enterprise agile. We have agile upstream and downstream practices. Not only is the business aligned on fast delivery cycles but our customer is taken into consideration when we deliver. We have common integrations between development and delivery tools. We can deliver in weeks, days or hours. And we are fostering a culture of experimentation, collaboration and learning.

Andre: That’s great. So which quadrant is right for a given organization?

Brian: Well, what I would say is that most organizations are candidates to be quadrant four companies, i.e. I will emphasize one particular attribute; where you are an organization that has embraced a culture of collaboration, experimentation and learning. And you’ve supported that with tools and practices that allow you to deliver quality software in days, weeks or months. So I think you can get from that description that most people can benefit from that. Now, where you may see a difference is look, we have companies out there delivering mobile applications or software as a service where they are small teams, they are already flat cross-functional teams and there’s not multiple teams to scale across. So those organizations would tend to strive to be a quadrant two organization. Any organization with multiple teams, applications or technologies should be striving to be a quadrant four organization.

Andre: So essentially what you’re saying is early adopters tend to start in quadrant one. Ultimately, I think what you’re saying is that organizations should strive to be a quadrant four organization. But the path between one and four could take a couple of different directions, correct?

Brian: Absolutely. You could be an organization that has some established agile practices in quadrant one. You then look to standardize those practices and standardize say continuous integration as a service by moving to quadrant three. And then you seek to move from quadrant three, which is the upper left-hand side all the way to quadrant four which is the upper right-hand side. Smaller organizations or organizations with more agile, smaller teams will take the path of going from quadrant one on the lower left to quadrant two on the lower right and then ultimately scaling those up to quadrant four in the upper right-hand side.

Andre: Got it. So as you go around and talk to companies about their DevOps maturity, do you have a sense for the distribution of companies across these four quadrants today?

Brian: That’s interesting. Well, first, let me take a detour to tell you that in answering that question and in talking to these companies, the power of the simplified view that I’ve recognized is I can now have a conversation with people where they say hey, I’m a quadrant one company. We want to get to quadrant two but we are really struggling because we can’t get our tools integrated or get everybody on board, for instance. So we now can identify where we’re at in simple terms with quadrant one, quadrant two, three, four. And directly to answer your question, what we are finding is that by far, the majority of companies are quadrant one companies struggling to connect upstream to downstream. In fact, specifically our statistics on our surveys average that about 40% of companies are stuck in quadrant one and over 85% of companies seek to be in quadrant four.

Andre: Interesting. Really interesting. So let me ask you, take a little bit of a detour here with respect to the quadrants and ask you how does this notion of pipelines fit into the quadrants?

Brian: That’s a good question. So again, you’ve heard me say it but I will repeat it. If we want to be able to release better software faster, meaning we have shorter cycle times, we can release with more frequency so we can gain and maintain competitive advantage. We: (1) need to automate and (2) we need to be able to automate across what our traditional silos. So our project management office, our development teams, our QA teams, our change management team and our operation teams. To do that automation, what we are effectively doing is constructing a software delivery pipeline that allows us to feed concept upfront and deliver to the customer on the output and do that in a reliable, repeatable way. So we take this concept of pipelines and pipelines really being a way that we establish automation for that reliability or repeatability. Now, as you are aware, Andre, the Jenkins community has released what I think is the future of continuous delivery and that is Jenkins Pipelines as code. And what Pipeline as code does or what Jenkins Pipeline does is it allows you to define that delivery process cross functionally in a unified manner such that all of the stakeholders can contribute to, access, visualize and monitor the delivery pipeline using proven software development best practices. Right? And again, I emphasize pipelines are about cross-functionally connecting teams to establish consistent delivery. By codifying that in Pipeline as code, we are providing a tangible mechanism to do that.

Andre: So you brought up an interesting point that I want to get your opinion on. So you talked about cross functional teams. So might pipelines be a way for different teams to collaborate on a common process?

Brian: Absolutely. And in fact, I hadn’t thought about it in the way you just said it, Andre, but you just inspired something. And really what it allows us to do, so we talked about realization and the struggles with that. How do I realize this approach across my legacy organization where we are split by different silos and different groups and different managers in different budgets? That’s a difficult problem. What Pipeline does do is it normalizes across all of those sorts of barriers such that to repeat what you said, we have cross functionally, we have a unified view of the software delivery pipeline irrespective of where we stand in the SDLC.

Andre: Yeah, that’s outstanding. I think that using pipelines in that way, not only to describe your end-to-end process, but also as a way for these different teams to collaborate really is, I think, one of the tenants of DevOps is this collaboration and as you stated at the outset here, empathy around what each other faces as they execute across those pipelines.

Brian: Absolutely. I couldn’t agree more or couldn’t have stated it better.

Andre: So if folks want to learn more about your DevOps maturity model, where can they go to learn more?

Brian: So we’ve released a white paper as well as I’ve executed or delivered a number of webinars. So I would encourage people that are interested to actually go to CloudBees.com and look under resources and there are a variety of resources that you can find there from talks around the Four Quadrants to whitepapers. And we also are making available a Four Quadrants self-assessment. And there is information within the whitepapers and those other assets on how to reach out to us, to get engaged with the Four Quadrants sort of DevOps maturity assessment as well as a free Jenkins assessment that not only monitors sort of the implementation of your tools platform but also takes into consideration your DevOps maturity in the context of Four Quadrants.

Andre: Excellent. So Brian, as you look towards 2017, what do you think 2017 is going to bring to the world of DevOps?

Brian: Oh, well, I’m going to extend on that realization concept, right? I think that DevOps is going to continue on this path of realization and it’s going to move from the domain of the few, the unicorns, that 10% that I noted, and it’s going to make significant steps to becoming the standard. Right? How we do things by default. It won’t fully achieve that. It won’t have penetrated every organization out there or everybody that delivers software. But we are going to make significant steps towards that. As part of this, what we are going to see is that those that have been sort of left out of the conversation when we just considered it, when it being considered Dev and Ops, i.e. those at the far left of the SDLC, the business, project management, etc. and those at the far right of the SDLC, security teams, quality assurance, scalability teams. They are all going to be better integrated into the process and we’re going to see more automation of things like functional and performance testing as well as security and compliance.

Andre: Nice, nice. So many of our listeners are in the midst of a DevOps transformation. Many of them are the managers leading DevOps transformations. What should they put on their Christmas list this year, Brian?

Brian: Eeew. How long is the list? All right, I’ll try to keep my list short because Santa may just leave me cold for DevOps for my DevOps request. So I’d say one of the things immediately that should be on their list is to wish for, meaning take tangible action towards ingraining a DevOps culture in their organization. And that is that culture of collaboration, experimentation and learning. So collaboration, you need to implement the ability for individual contributors to communicate as needed. So establish processes as well as tools such as Hip Chat, Slack; where you can have normalize conversations across individual contributors. Experimentation. You need to enable your teams to move fast and you need to encourage your team to take chances; just ensure that they have a safety net and safeguards in place. And really place a value on learning. So I’d start with give me a DevOps culture for Christmas, right? Because it’s going to be that DevOps culture that will then better ensure you get that next gift under your tree, right, and that is sort of unifying tools and technology that allow different stakeholders in the SDLC as well as different teams with different technologies; your mobile team and your web team to be able to collaborate in the standard manner such that they all can begin to have the reliable and repeatable delivery process that’s required for DevOps. And what I’m also going to tell Santa, as I’m going to tell Santa that I have a wish for next Christmas. And my wish for next Christmas is that we have made enough progress with our culture, our tools and technology as well as our processes that next Christmas, I can do away with the concept of DevOps specific teams and we find that that’s just the way our organization operates.

Andre: Ho ho ho. That’s a great list, Brian. Hey, so thanks very much for being with us today. Is there anything that I didn’t ask you about that you’d like to discuss with our audience today?

Brian: I guess just maybe a couple of closing points, right? I’m pretty passionate about this stuff, about sort of optimizing the software development process and DevOps as being a way of doing that. I also have had the pain and privilege of being part of some of those transformations and observing some obstacles in developing sort of opinions. So to that end, I’d like to make a couple of suggestions to people that are looking at doing this. One, as you’ve heard again but I will beat it in, be aware that there is no silver bullet. You cannot just buy a tool and be DevOps nor can you just focus on culture and be DevOps. You really need to focus on that Trinity of people and culture, process and practice, tools and technology. Two, don’t get caught up into thinking again that it is just a technical domain. We’ve automated our deployments. We are DevOps. No. Keep in mind that it is concept to customer. You need to be able to deliver an idea, get that out to market, determine if it delivers value, take metrics and capture feedback that then can inform your next iteration. And then lastly, don’t expect this to happen overnight. I don’t recommend the Big Bang approach. I always say be pragmatic not dogmatic. And value incremental change over Big Bang change. As we start this and try to apply what we are hearing in the market to our organization, we don’t always know what we don’t know. So take an agile approach, get going and iterate and improve in the process.

Andre: All right, Brian. Thanks very much for joining us today. And for those of you that like to learn more about the DevOps maturity model that Brian has developed, you can go to CloudBees.com/resources/whitepapers. It’ll be the first whitepaper on the list there. Thanks very much.

Brian: Thank you, Andre.

Andre: Thanks for joining us on DevOps Radio. Like what you’ve heard today? Don’t miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz, follow CloudBees on Twitter, Facebook and LinkedIn.