RunSafe Security this week added an ability to generate a software bill of materials (SBOM) based on the code actually included in an application before it is deployed in a production environment.
The RunSafe Security Platform already enables DevOps teams to safely run code written in languages such as C or C++ by reordering how code is actually executed. That capability prevents cybercriminals from creating, for example, a buffer overflow that exploits a known vulnerability by preventing them from discovering where to inject malicious code.
In addition, the RunSafe Security Platform provides access to monitoring tools that enable DevOps teams to track what components running in memory are being used to build an application. That capability is now being extended to generate an SBOM.
RunSafe Security CTO Shane Fry said that approach creates a more accurate SBOM because unlike other approaches it is not generating an SBOM based on what source code was used or, conversely, trying to analyze application binaries. Both those approaches create SBOMs that are often inaccurate or incomplete, he said.
DevOps teams then have to create a process to manually triage SBOMs using senior application developers that are costly to hire or contract, noted Fry.
In contrast, The RunSafe Security Platform tracks what code is being loaded into an application, either directly from within a continuous integration/continuous delivery (CI/CD) platform or server being used to build software, said Fry. In total, the RunSafe Security Platform keeps track of more than 400 sources of application vulnerabilities to ensure the SBOM created is accurate. They can then opt to safely deploy software with known vulnerabilities by reordering how code is run in memory, or use those insights to better prioritize remediation efforts. noted Fry.
With the rise of more stringent regulations and compliance mandates, the number of DevOps teams now required to provide SBOMs every time an application is deployed or updated has expanded greatly. The challenge is that the SBOMs, rather than providing a precise accounting, represent more of a best guess of what’s been included, said Fry.
It’s not clear to what degree organizations are relying on SBOMs for anything more than complying with a mandate, however, wherever a new vulnerability is discovered knowing exactly what code is running where becomes crucial. Many DevSecOps teams, for example, in the absence of having any SBOM at all are still looking for where all the vulnerable instances of a Log4j tool for monitoring Java code might still be running, more than a year after the issue was initially discovered.
In theory, of course, many organizations are moving to convert unsafe code into another language such as Rust, but those efforts will take many years to complete. In the meantime, when it turns out that the SBOM provided is incomplete or inaccurate there will be an inevitable backlash. Most mandates require an SBOM but don’t have any specific accuracy requirements. It’s largely up to each organization to determine to what degree to comply with the letter versus the spirit of the mandate.
Ultimately, however, there will come a time when a DevOps team that created an SBOM will be called to account for its veracity when the next application security crisis inevitably ensues.
The 4th annual DevOps Enterprise Summit (DOES) in San Francisco this week was, in my opinion, the best one yet. Lots to report about, but I wanted to call out a new trend I am seeing that I call the DevOps Cha-Cha. You remember the Cha-Cha: three steps forward, two steps back, cha-cha-cha. Actually besides being a great dance with the right beat, that same three-steps forward, two-steps back is about what you would expect from large enterprises that are undertaking profound digital transformations.
I say that this is normal because, despite all the great firsthand accounts of DevOps transformations on display at DOES this week, there was a bit of a whispered undercurrent. More than several people I spoke to talked about the fact that “this DevOps thing isn’t that easy.” Others spoke about the large number of “failed DevOps transformations or implementations.” Obviously, as the editor in chief of devopsy.kinsta.cloud, I might have a skewed view of this, but let me put in my 2 cents and then some on this subject.
DevOps Transformations Are Not Easy
First of all, no one ever said DevOps transformations would be easy. I’m not sure why anyone would even think that. Changing cultures can be gut-wrenching. Sometimes it means replacing people who just can’t wrap their heads around a new culture and way of doing things. Other times it means ripping up the way people and teams interact with job roles and positions. Change is never easy. Frankly, if it was easy, everyone would have done it already. That is just the cultural piece. Imagine coupling that with new tools, new processes and new ways of building, testing and deploying software. Again, I’m not sure why anyone would think such an undertaking would be easily accomplished.
Is anything truly worthwhile ever that easy, though? The real question is, Is the pain and trouble worth it? If you were at DOES this year or have read other success stories around DevOps and digital transformation, I think you will find the answer is, “You bet it is.”
If you go into a DevOps transformation thinking it is going to be easy, you are setting yourself up for disappointment. Doing DevOps is not just a matter of being one of the cool kids on the block or trying something new for kicks. It means you are dedicated to seeing it through. It means you are going to think through, plan, learn and do what needs to be done.
Failure Is Not An Option
Also important to keep in mind—and this is really the meat of it—is that DevOps transformations shouldn’t and don’t proceed in a smooth linear manner. While at a macro level over a period of time you should be able to discern progress (depending on how you define progress), when you drill down you find fits and starts, steps forward followed by steps backward. There also will be steps sideways and sometimes no steps at all in any given moment. But like life itself, that is how DevOps transformations go.
I was speaking with someone at DOES (I don’t remember this moment who), who told me every business plan they had ever seen had revenue growth like a hockey stick—just straight up on sharp angle. The same is true for the benefits realized in every DevOps transformation plan. If only DevOps and life worked that way. It is the rare bird that has shows a revenue line that is straight and angled that way.
Real life is filled with starts and stops. You learn from your mistakes; you get it right the next time. Sometimes you need to take a step back to take more steps forward. DevOps is no different. It is not homogenized and doesn’t always (if at all) proceed smoothly. The real test is whether over a longer period of time you are achieving your goals (did you even define your goals or just thought DevOps would fix everything?). You can’t look at any given moment or event and say, “Our DevOps transformation was a failure.”
Your DevOps transformation is only a failure if you end it before you get started, or before you can overcome the roadblocks in the way. At its heart DevOps means we keep improving. Think of those failures and feedback loops. You do your post mortem, you learn from your mistakes and you keep plowing ahead. It is only a failure if you let it be one by stopping.
The DevOps Cha-Cha
In my opinion, you look at your failures during your DevOps transformation and you make lemonade from those lemons. You learn from them and keep moving forward, one foot after another. Imagine a hot Latin beat in your head. Start moving, one, two, one-two-three, one, two, one-two-three, that’s it—now you’re doing the DevOps Cha-Cha. Keep the beat, keep dancing and keep doing DevOps.
More DOES Coverage
If you are interested in hearing what some of the speakers, attendees and sponsors of DOES 2017 in San Francisco have to say, be sure to visit our DevOpsTV YouTube channel, where we have a DOES San Fran 2017 playlist. There are about a dozen videos up there now, but will be adding to that every day as editing completes.
In a special episode of Electric Cloud’s Continuous Discussions (#c9d9), Gene Kim and speakers from the upcoming DevOps Enterprise Summit San Francisco (DOES17) discussed the deployment age, and how DevOps practices and automation can unburden teams and boost productivity.
The panel included: Mik Kersten, CEO of Tasktop; Robin Yeman, fellow at Lockheed Martin; Courtney Kissler, VP of digital platform engineering at Nike; and, our very own Sam Fell and Anders Wallgren.
Continue reading for some of their top takeaways:
Kersten discusses the importance of spreading the word about DevOps tooling: “I think the best thing we can do is accelerate this turning point by giving the rest of those 15 million developers working in all of those other companies the tools that they need to apply these technical practice and to reorient their organizations to actually leverage them.”
Yeman on the multiplier effect of automation: “DevOps is definitely all about the people, but the automation enables people to have such a higher outcome and better business results. It’s almost like a force multiplier for companies.”
It’s crucial to look at the bigger picture of software delivery, advises Wallgren: “If you don’t have a big picture of what your value stream is from one end to the other, it’s hard to convince people that the problem they’re looking at is in fact not the right problem to be focusing on, or whether that is the right or wrong problem.”
Organizations that employ transformational leaders succeed, claims Kim: “We see people driving DevOps transformations in large complex organizations, specifically the DevOps enterprise community, and my claim would be that these people are being promoted at a rate far higher than the population at large. My interpretation of this is that the value that’s being created by these leaders is appreciated and they’re being put into roles where they’re being asked to make an even greater contribution across even a broader portion of the organization.”
You can’t just optimize for cost and efficiency anymore, explains Kissler: “There’s this realization that we’re all shipping software and really embracing that and understanding that organizations that have typically optimized for cost and efficiency are not going to win. And so, optimizing for speed to value, the value stream is a huge shift as well.”
Yeman explains the awesome leadership structure at Lockheed Martin: “At Lockheed, most business leaders were engineers at one point in time. So, if you’re looking at the President or the Vice President, they started out in software, or systems, or as a tester. They have to have depth in their area because then they can really empathize with what we’re building and with, you know, the people that are building it.”
More on the wonders of automation, per Kersten: “Agile has scaled up, but it kind of hit a brick wall until automation came into play and organizations realized that they needed reliable, predictable, and safe ways to deploy. I think one of the most interesting things that happened when the technical practice matured around that automation layer is all of the other gaps it uncovered.”
Wallgren on the ironic manual nature of the software delivery industry: “I think that one of the paradoxes of what we do in software teams is we don’t use software at all, most of the time, to help us produce our own software. We use people.”
Kim reflects on revelations after reading “Disrupt or Die” by Jedediah Yueh: “The real value that DevOps will create is not going to be in the FAANGs, the Facebook’s, Amazon’s, Apple’s, Netflix’s, and Google’s of the world, but it really is in the large brands in every industry vertical as they either disrupt, get digitally disrupted, or digitally disrupt themselves.”
Kissler on how to respond to the exponential growth of digital disruption: “I think the acknowledgement of where we’re at and where we need to go and how fast we can get there is a huge component of responding to the digital disruption.”
Watch the full episode:
Want more Continuous Discussions (#c9d9)? We hold our #c9d9 podcast every other Tuesday at 10 a.m. Pacific. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.
As DevOps Enterprise Summit San Francisco (DOES17), slated for Nov. 13-15, inches closer, event founding partner Electric Cloud hosted a special episode of Continuous Discussions (#c9d9), featuring some of the conference speakers. During the discussion, the speakers shared some of their recent DevOps transformation stories and a bit about what to expect during their talks at the conference.
The panel included:
John Esser, senior director of IT and data center operations at AdvancedMD;
Gary McKay, scrum master at Somos;
Aloisio Rocha, agile product owner at NetEnt;
Manish Aggarwal, software engineering manager at Intel;
Marc Priolo, global software configuration manager at Urban Science;
J. Paul Reed, managing partner at Release Engineering Approaches;
Marc Hornbeek, principal consultant – DevOps at Trace3;
Gary Gruver, founder and CEO of Gary Gruver Consulting; and
our very own Sam Fell and Anders Wallgren.
Here is a list of the most memorable takeaways from the discussion:
Every company is different, so approaching a DevOps transformation will vary based on the organization, explains Esser. “Every company has a different set of constraints, a different culture, different things they value. So you can’t just say, ‘Oh, I’ve got this DevOps hammer, and I’m going to start pounding away.’ We understand the principles, but how to apply those and how to execute those principles are quite different.”
McKay on the success of moving from mainframe to microservices with his “Team Dragon” concept: “Team Dragon was formulated to make sure that our CI/CD process as well as our deployment and release processes were consistent. Coming from a mainframe environment to, say, a distributed microservices environment, there are differences not only in culture, but processes and technology. We wanted to make sure all that was managed efficiently and effectively, so that we could do deployments when we needed to do deployments.”
Rocha on the NetEnt DevOps journey and what inspired the transformation: “We’ve gone from a place where the business was expanding, but deployments and deliveries were not scaling with the business to working on how to tackle it with automation, working with the deployments and making the deployments visible to everyone.”
Aggarwal will be talking about the DevOps journey at Intel at DOES17: “I will be covering as to how a lot of organizations, including Intel, are trying to board the journey of DevOps. They are successful to an extent, but how to make sure that the quality, which is the sole purpose of this journey, does not get left behind.”
Priolo on his pipeline-as-a-service strategy: “We have a pipeline-as-a-service strategy. That’s where we want to make sure that our developers can concentrate on developing instead of trying to figure out how their code is getting into our production environment.”
Gruver’s simple advice on starting your DevOps transformation: “In the beginning, you need to create some positive momentum. You need to find the things that are the most broken in the development and deployment operations. You need to highlight them. You need to get them fixed. Then you need to market those changes, so that you get some positive momentum for the transformation.”
Don’t forget about the human factor of release engineering, says Reed: “[At DOES17] we’re going to be going through a little bit of the human factors that are related to release engineering. There’s a couple of facets of that. It’s sort of, ‘How do you go about doing the work,’ and then also a bit about how we treat others, the net system.”
It’s important to include all teams on your transformation journey, per McKay: “The secret is inclusiveness. Making sure that the mainframe team is part of the microservices process and making sure that we, in our haste to get things done very quickly and very effectively, make sure that we bring them in. We make sure that their roles are purposeful and that they’re part of the process and not just, ‘Oh, you’re just some mainframe guys. We’re just going to ignore you.’”
Esser on the core values of DevOps: “DevOps as a whole is not limited just to an architecture. DevOps, at its core, is about working better together and increasing the flow of value across the whole value pipeline.”
It’s important to find the right balance between allowing your developers to be unique, but also adhering to the rules, says Priolo: “The real challenge is trying to find out a way to allow developers to still have their snowflake ability, while still complying with the standards of the company. It’s not to make everything stringent and follow the same exact path. It’s to create a pipeline that gives them the flexibility, but still gives us the ability to do auditing, to make sure that the code is being checked at its proper place.”
Sometimes it takes a big mistake or bug to make you realize you need DevOps, explains Rocha: “Our process was intense before, to say the least, especially when some scary bug came or a heavy compliance requirement came in that we had to fulfill in a short amount of time. That made us realize we have to fix this.”
Wow – Aggarwal’s team at Intel went from almost complete manual testing to 100 percent automation in seven years: “When we started about seven years ago, 99 percent of our testing was manual, and everything was repetitive. The work was getting more challenging, and the sheer amount of it was growing with every release. So it was very important to bring that under control. The only way of doing that was end-to-end automation. When I say, ‘end-to-end,’ it’s not 99 percent. It’s 100 percent totally touchless automation.”
Reed on the human factor of versioning: “Versioning really is about humans communicating with each other. They’re trying to encode information into that version number, which is, I think, one of the reasons you see people bikeshedding that a lot.”
DevOps can expose your longstanding problems, says Gruver: “When you start trying to increase the frequency of build/test cycles or deploy cycles, you see inefficiencies repeating. You see the trends. There’s a bunch of tools in the DevOps toolbox that enable you to go after that.”
Moving from monolith to microservices is not an overnight transition, explains Wallgren: “Time and time again we hear the difficulties that everybody has with legacy applications or monolithic applications. The transition away from mainframes is not an overnight kind of thing. They’re not going anywhere, anytime soon.”
There’s still value in mainframes, and getting that to customers is key, explains Fell: “There’s a ton of value locked up in mainframes and being able to get that out to other people in a service-oriented sort of way. It’s a hard migration to do, but that cultural aspect of making teams feel like they’re comfortable working with one another is critical to getting through that part of the process.”
Watch the full episode:
About the Author / Anders Wallgren
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.
In this DevOps Chat we speak with Rob England, the IT Skeptic. Rob joins us from New Zealand (you have to love the internet). Rob is going to speak at this year’s DevOps Enterprise Summit London, June 5-6, about the importance of taking care of your people in the DevOps transformation process. Rob is always an entertaining fellow and this chat is no different. If you are attending DOES London this year, you don’t want to miss his session!
As usual, the streaming media of our conversation is immediately below and the transcript of our chat follows that:
Transcript of the Chat
Alan Shimel: Hey, everyone. This is Alan Shimel from devopsy.kinsta.cloud here for another DevOps Chat. We’re lucky to be joined on this DevOps Chat by a friend of mine and a person who’s actually appeared before on our DevOps Chat, all the way from New Zealand: Rob England, the IT Skeptic. Rob, welcome to DevOps Chat.
Rob England: Hi, Alan, and, hi, everybody. It’s a pleasure to be here.
Shimel: So, you know, Rob, actually, I didn’t ask, but are you back home in New Zealand right now?
England: I am, so I’m about to have my breakfast. [Laughs]
Shimel: Okay.
England: Tomorrow. Your tomorrow. So –
Shimel: Yep, it’s my tomorrow. You’re already living my tomorrow—that’s interesting. So, Rob, of course, I think you’re well known within the DevOps community and the IT community at large, but, for anyone who’s listening may not be familiar, why don’t you give us a quick little background?
England: Okay, thank you. Yeah, so I come from a service management background, so I have a bit of a presence internationally with a small blog that got a service management following, so that’s how I sort of became internationally networked. And, originally, I was a bit of a skeptic of the whole DevOps thing, but I was gradually turned, by Gene Kim and by John Willis and by Jez Humble and others, into a bit of an enthusiast, and now my whole life is DevOps, really. I consult here in Wellington, New Zealand to the DevOps community and I’m working with a couple of the largest government departments here in New Zealand now, helping them on their DevOps journey.
Shimel: That’s just great. And, Rob, you’re traveling from New Zealand to London, June 5th and 6th, for this year’s DevOps Enterprise Summit, DOES London. It’s at the –
England: I am.
Shimel: – QEII Conference Center. And you’ll be speaking there as well.
England: I am. Oh, I’m really, really pleased and honored to be selected to speak; I think that’s fantastic.
Shimel: I think it is too. So, Rob, we’re lucky enough to interview a few other speakers from DOES—not only from London but in past DOES events in San Francisco, but can you give our audience a little bit of a flavor for what it’s like or what’s the process like or what motivates one to go speak at a DOES event?
England: [Chuckles] Oh, in this case, what motivated me was Gene Kim, so I was talking to him about some of the people stuff that I’m quite passionate about, and he said, “Hey, you should write that up and submit it,” so I did. And, from there, it was pretty straightforward—I put all the details in and had my proposal accepted—so that’s very exciting. As I say, I’m very passionate about the people side of things and the cultural change, and the focus for this presentation is around taking care of our people through that transformation.
Shimel: Excellent. And so, Rob, when you mention people like that, I’m reminded or brought back to a—I think it was Adrian Cockcroft’s presentation in San Francisco this past—don’t remember if it was October or November, but you may remember. And Adrian’s presentation was very much that,“Hey, people are your most valuable asset and you gotta treat them right. And, when you think about the money you spend on tools and all of these other things, it pales in comparison to the importance of spending money on people.”
England: Yeah. Absolutely. In the past, even before my DevOps life, I used to write about how, if you look at any project, when we’ve had projects, and how the money was allocated within that project, if it wasn’t sort of one-third people, one-third process, one-third tools, then you had a very strong indicator it wasn’t gonna be a successful project.
Shimel: Mm-hmm. Repeat that again, though, ’cause you know how you New Zealanders are – you talk so fast. [Chuckles] That it was one-third, one-third, one-third?
England: Yeah, yeah, yeah. So one-third people, one-third practices, one-third tools. If it’s not something like that, it’s very typical to see project proposals that are going to spend 50 percent of their money on installing the tools and 50 percent of their money on redesigning their processes—oh, and, by the way, there’s a day’s training. You know, and it’s like, well, there’s nothing else recognizably about workshopping with people or collaborating with people or, you know, coaching people or all the other people aspects. It’s very common to see projects that are not planning to spend any money on all that, and I think that’s a –
Shimel: I agree.
England: – a formula for failure, right?
Shimel: Yeah, no, it is. I mean, we tend to take the people part of it for granted, and, just as you said, you don’t spend the money on it, will spend a ton of money on tools and infrastructure. Right?
England: And I have to say, I think that’s one of the two primary reasons why service management initiatives were so often unsuccessful, was that, I thought, didn’t coach us enough to focus on the culture and the transformation, and we spent too much time on process, so DevOps—for me, the power of DevOps or a big part of its power is it’s focused on people and culture.
Shimel: I have to agree with you. I have to—you know, Rob, I’m reminded of, back in my security days, the co-founder of StillSecure, I went to visit a rather large bank out in New York, and it was about vulnerability management. And we were talking about the vulnerability management program they had in place and I mentioned to ’em that the way they were doing things, it was forcing his security team not only just to scan at night, which is, you know, normal, but to actually only do remediations on weekends.
England: Mm-hmm.
Shimel: And I said, “You know, that means that your security team is working every weekend, in addition to working during the week, ’cause you don’t have enough people to stagger that.” And he said, “I don’t care. I pay them by the week; I don’t pay them by the hour. I don’t care if they work seven days a week.” And that –
England: There’s a good boss, eh?
Shimel: Yeah, no, that’s someone you’d wanna work for, right? But this, unfortunately—you know, we talk about culture and the whole “Kumbaya” thing that many people kinda try to say with DevOps, but it’s real. You gotta treat your people as your greatest asset, and that was Adrian’s message, right, at DOES San Francisco. They’re not –
England: That’s powerful.
Shimel: Yeah. And they—if you treat ’em like crap, crap is what you’re gonna get, I’m afraid.
England: Absolutely. And my particular focus for this presentation is about the effect of the transition on people in your organization and, in particular, there’s this “Get on the bus” thing, but we don’t wanna actually throw people under the bus, so it’s giving people the opportunity and the time to grow and to make the transition. There’s very often a “revolution, not evolution” thinking in management’s mind: “Are we just going to change everything?” And, again, we’re very neglectful of the fact—the old bell curve—we’re very neglectful of the fact that just because a few people are coming along doesn’t mean we—we still have to allocate more time for the great masses to get their head around this thing and absorb some of these really quite challenging and radical concepts that underpin Agile and DevOps—it does people’s heads in, as we say down here.
Shimel: Yeah. So, Rob, let’s talk about that a little bit, if we can. You know, you’ve now consulted, as you said, with a bunch of government departments and companies, both in New Zealand and in other parts of the world. What, from a people point of view, what is the hardest things that these guys or these people have to kinda wrap their heads around to make it successful?
England: Oh, I’m sure the biggest challenge is getting—well, actually, one of the biggest challenges is getting away from that silo-ed thinking, and so the other power of DevOps, along with its focus on people, is its focus on systems and systems theory and systems thinking. And so I think that they struggle to get out of their silo and start thinking holistically and seeing the whole flow of value and understanding their role in that. That is a big challenge to just about everybody.
Shimel: Agreed.
England: Then there’s also—yeah. And then there’s also peculiar challenges to each organization as well, right? So I’m thinking of one where a particularly psychopathic CIO had moved on, and it was trying to teach people that, “It’s okay now. You can come out from under your rocks, you know? It’s gone.” So that’s –
Shimel: “Out from under your rocks.”
England: Yeah. That’s a—they all sort of crawled away into shelter, you know? And so that’s the peculiar problem in one situation. So there’s—you know, every place has its own challenges, but a universal one is that siloed thinking and another universal one is just the letting go of the—do you remember the Bastard Operator from Hell, BOFH, or –
Shimel: Mm-hmm.
England: – or Dilbert‘s Wally? You know, these characters that—it’s considered funny in IT that people have dysfunctional behaviors and are misanthropic, and part of the DevOps message is just we don’t tolerate that anymore. That negativity is not allowed—we just don’t tolerate it—and getting rid of some of that old cynical bitter and twisted IT thinking is also a common challenge.
Shimel: I agree. I agree. And you know what? I think part of it is not only the negativity from whether it be a supervisor or peer; I think the other biggest thing that I personally see and when I talk to organizations around DevOps and stuff, and not just dev and ops—when I talk with QA and security and management and so forth—is the finger-pointing, is the—it’s almost like American politics, I’m sorry to say, in that “Yeah, I know this is screwed up, but blame the other guy,” or “If you think this is screwed up, you should see how screwed up the other guy is.”
England: Absolutely.
Shimel: You know? “And it’s not my fault; I inherited a mess,” and all of this kind of thing where one of the refreshing things about DevOps is it started with the blameless postmortem, but it’s more than just a blameless postmortem—it’s about “Stop pointing the finger and let’s work on solving this together, instead of just saying, ‘Hey, it’s this mate’s fault and it’s his problem.’”
England: “I’ve got your back.”
Shimel: Yep. I mean, and that –
England: I’ve got your back, buddy.”
Shimel: You know, and that may sound hokey and “Kumbaya-ry” and all that, but, really, I think that’s when you start building a team.
England: There’s a really good cartoon, that might be a Paul Wilkinson one, where the ops guys are at one end of the boat, looking down at the dev guys at the other end of the boat, trying to deal with a fountain of water and saying, “Not my problem, not my end of the boat.”
Shimel: Right. Uh-huh. Exactly. And we’re all on the same boat, though. So –
England: Yeah. Yeah.
Shimel: So this is a real thing. Rob, other than DOES, have you been talking about this kind of subject at other events and so forth?
England: Oh, for sure. So, actually, it’s been an interest of mine since before I was consulting. I used to work in—for my sins, for a vendor, and I used to do work on professional development there and trying not to let the technical people fall under the bus and trying to get them to skill up to be consultants, rather than just product jockeys. So I’ve worked and talked in this field for a long time, just as a personal passion. I hate to see good people lost, you know, just because their organization failed to make sure they were coming along and to take care of them.
Shimel: Sure. Sure.
England: So that’s a long-term passion, but this particular topic now I’m hatching especially for DOES, to put together a presentation specifically about the DevOps implications of—it’s called “Surviving DevOps,” so making sure everybody’s—it’s not just that you individually survive, but that “no person left behind,” you know, as well.
Shimel: I agree with you. So, Rob, geez, I’ve met you—wasn’t this year’s San Francisco DOES; it was last year’s. So it wasn’t 2016; it was 2015 DOES San Francisco. And we’ve, of course, seen each other several times since, but –
England: And, you know, I’m one of the few people in the world who’s been to every single DOES in both the U.S. and the UK.
Shimel: So I think I’m one of them too, actually, but –
England: Yep, you would be.
Shimel: Yeah, which is interesting, when you think about it that way. But let’s—I mean, many in our audience may not have been lucky enough to even get to one, let alone five or six of these things. Can you give our audience a flavor of why? Why do you keep coming back? Why did you feel compelled to wanna speak at this one? What makes this a great event in your mind?
England: Well, I think it’s the fount of knowledge for DevOps, especially DevOps enterprise, so my interest is DevOps for hoses, not DevOps for unicorns. And, very much, the focus of the enterprise conference is around DevOps in the real world, DevOps in the enterprise world, so that’s the first thing. The second thing is that Gene does a fantastic job of focusing and coaching presenters to make sure that their presentations are really short and pithy and full of value, and they also make sure that the presenters are practitioners, so there’s not a lot of talking heads, except for some really high-value experts like John Willis and Jez Humble and Adrian Cockcroft, the people who are up there purely because of their intellectual strengths. But most of the speakers are there because they’re reporting back from the coalface about their own experiences and learnings, and so that, to me, is gold.
Shimel: Yes. Any—well, I guess that kinda says it all, Rob. If anyone had any doubts about whether they’d wanna go to this or not, that clears that up. Rob, anything else happening exciting around DevOps you think people should be on the lookout for?
England: Oh, well, I’m not sure about _____ – the value for me is that I live on the last rock on the planet, so I actually get quite a different lens on DevOps than perhaps those, like yourself, immersed in the big economies and big societies, and, certainly, it’s going gangbusters here. There’s a huge wave of interest in the mainstream—in government, in the airline, the banks—and I’m gathering that that’s not necessarily the case everywhere in the world, so, you know, I think that –
Shimel: No, I think it is. I really think it is.
England: Yeah. Yeah. But they’re not just dabbling anymore, right? They’re actually transforming; they’re restructuring the way they go. And, to me, that’s the excitement of the moment, is that this thing is mainstream. You know, it’s bridged the chasm. Remember the Star Wars book about crossing the chasm? You know, the –
Shimel: Yeah. Sure do.
England: – DevOps has gone from the early adopters to mainstream now. It’s definitely –
Shimel: Oh, it’s certainly mainstream, but I –
England: – the majority.
Shimel: So I think it’s in the early majority, though, not the later majority.
England: That’s true. That’s true. It’s still not everyone; it’s still not—but, yeah, but it’s certainly jumped—it’s certainly bridged the chasm and it’s on its way up that curve.
Shimel: Oh, no doubt about that. No doubt about it and, hey, we live it every day here at devopsy.kinsta.cloud, as we continue to kind of chronicle all this. Anyway, Rob, we’re about out of time. I wanna thank you for joining us all the way from New Zealand. Look forward to seeing you in London and your presentation and thanks for doing everything you do, Rob. I mean, you know, you’re a healthy IT skeptic. In IT, skepticism is healthy, right?
England: It sure is and I love doing it. Thanks, Alan. It’s always a pleasure to talk to you, my friend.
Shimel: All right, Rob. You be well. We’ll see you in just a couple—well, it’s about two months now, probably.
England: See you there.
Shimel: All right. Rob England, IT Skeptic, speaker at DOES London on June 5th and 6th at QE Conference Center. This is Alan Shimel for DevOps Chat. We’ll see you soon on the next DevOps Chat.
The results and analysis of the State of DevOps Report 2017 report are due out in early June. just in time for the DevOps Enterprise Summit London June 5-6. In this DevOps Chat we speak with Puppet exec and one of our favorite interviews, Nigel Kersten.
Of course, Nigel and the folks over at Puppet have been co-producing the State of DevOps report and survey for six years now. For this year, Nigel along with Dr. Nicole Forsgren and Jez Humble of DORA, will be co-presenting at the DOES London, where they will announce the results of this year’s survey. It should be quite interesting.
Nigel gave us some sneak peeks and early trends for this years report, as well as discussed the DevOps Enterprise Summit and, as usual, some good info on what is happening at Puppet and the DevOps world in general.
You know the drill by now: The streaming audio of our conversation is immediately below and the transcript of our conversation is below that. Enjoy!
Streaming Audio
Chat Transcript
Alan Shimel: Hey, this Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. And we’re happy to be joined again by a repeat guest on DevOps Chat, none other than Nigel Kersten of Puppet. Nigel, welcome.
Nigel Kersten: Hey, Alan. Nice to talk to you again.
Shimel: Good to speak with you. So, Nigel, we’re not talking about the latest and greatest from Puppet today. Well, maybe if you wanna just mention it quickly, feel free, but I wanted to really talk a little bit about the upcoming DOES London event, Gene Kim’s DevOps Enterprise Summit, which is June 5th and 6th in London at the QEII Center, and you will be presenting there. Correct?
Kersten: I will be. Yep, with Dr. Nicole Forsgren, who’s one of the other authors of the DevOps report, and DevOps Enterprise Summit London last year, I think, was honestly one of the best events I’ve been to in this space for a long time and I adore London for lots of reasons, and so it’s always great to be back there.
Shimel: Yeah. And, Nigel, correct me if I’m wrong – is Jez Humble also presenting with you and Dr. Nicole?
Kersten: I think Jez probably will be, but I’m not sure if it’s quite confirmed yet. We’re sort of trying to work out how we’re covering all of the different events, for the various roadshows and webinars we’re doing around the DevOps Enterprise Summits and the DevOps enterprise report.
Shimel: Yep. Okay, so I guess we’ll stand by for final confirmation on that, but, certainly, you and Dr. Nicole will be on, and, of course, Nicole has appeared on our show before and we’ve talked a little bit about not only this year’s DevOps survey but past years’ as well. But, Nigel, for some of our listeners who maybe weren’t lucky enough to hear previous talks about it, this is what? The sixth or seventh year of the State of DevOps survey?
Kersten: This is the sixth year, which is kind of amazing ’cause, you know, I think, when we first started with the fantastic Alanna Brown, who also works here at Puppet, everyone was a bit skeptical about it. I think this was even before you’d started devopsy.kinsta.cloud and people were like, “Is this really a thing? Do we really need a survey about all of this?” but I think it’s just gone from strength to strength over the years. So, yes, I guess, for the people who are sort of new and may not have come across the report before, what we essentially do is we survey a whole bunch of practitioners—we’ve done tens of thousands of ’em around the world over the last six years—and what we do is we ask about the practices and the tools that they use, but also some metrics about “What’s your mean time before failures? How quickly can you deploy your software? What sort of practices do you use?” as well as what sort of outcomes you have. And then we do a statistical analysis on all of that so that we can—and we actually end up showing that there’s a huge gap between what we call “high-performing” IT organizations and everyone else.
And, in fact, interestingly enough, over the last few years, we’ve shown that the gap is increasing over time, so the people who’ve adopted DevOps practices—because, essentially, what we’re showing is we’ve been able to show statistically that what we tend to call “DevOps practices,” around using CI, using CD, using infrastructure-as-code software, doing continuous deployment, using testing, storing things in version control, all of these practices, when you cluster them, are the people—the people who employ these practices are the people who have high-performing organizations. And they’re really huge statistics—they tend to be thousands of times better, being able to deploy just ridiculously faster—and, essentially, what this ends up showing is you really don’t have to sacrifice quality for speed or vice versa, so we’re seeing that these people are both producing high-quality infrastructure and applications and they’re doing it far more quickly than everyone else.
I think one of the things I’m really proud of with the DevOps report is that it’s useful to sell DevOps practices within your organization, so I talk to an awful lot of customers and practitioners out there who are really thankful for the report because it tends to be focused on business outcomes. So, even though we’re surveying practitioners, it’s something that’s really applicable to C-levels and VPs and directors. They can look at this with them and go, “Ah, this is where the industry’s moving and these are the sort of benefits we’ll actually get.”
Shimel: Excellent. And, Nigel, in typical humble Nigel self, you’re—I mean, let’s give a little bit more flavor, if we can. Over the five previous years, I think there’s over 25,000 responses to these surveys.
Kersten: Yeah, no, that’s right. 25,000 over five, six years. It’s pretty crazy.
Shimel: So that does represent a—in a field like DevOps, which is fairly new, right, it represents a sizable amount of people and organizations who have taken the time and contributed to the data that you guys have analyzed over the years. And another important thing, I think, to note for our audience is not only the analysis of the data but even the questions themselves are, from a statistics point of view, a statistician’s point of view, rigorous—rigorously designed and rigorously analyzed. And, look, having a Ph.D. statistician helping you with it doesn’t hurt, but so these are not just some –
Kersten: No, it’s not your average –
Shimel: – go up and doing surveys.
Kersten: – sort of marketing survey at all, and I think this is why it’s always really important for us that—you know, we’re a software vendor and we’re in this space and there’s a lot of people in our space who do pretty fluffy kind of surveys that only take two or three minutes and then some sort of ridiculous claim gets made, so this is why we’ve always been really keen on working with the external parties of Gene Kim, Jez Humble, Dr. Nicole Forsgren. Particularly Nicole. She’s a trained statistician who’s literally got a Ph.D. and has spent her career working on studying organizational performance, which overlaps with DevOps in really interesting ways, but I think having that external rigor, and I think it helps keep us honest as a software vendor. So this is something we really loved, having a partnership with them, ’cause this is their specialty.
They actually—to give them a little bit of a plug, they have their own organization, DORA, DevOps Research and Assessment, where they’ll come in and do benchmarking of your organization and actually measure how you’re actually doing, so I think it’s just really great. We’re clearly really plugged in as Puppet into this whole community, but they plugged in at a different level, and working together, I think, means that we both get to expand reach and bring a bunch of statistical rigor to something that could easily devolve into a self-serving survey, which ultimately doesn’t –
Shimel: Hey, Nigel?
Kersten: Yep?
Shimel: I thought I lost you there for a second. I apologize. Agreed, I mean, on all of the above. And that’s really—I want people to understand that, that this isn’t a marketing survey they up and have done now for six years running. I wanted to make another point, Nigel, and that is, certainly, over the last two years at least, and I would imagine for this year as well, one of the real nuggets of wisdom that have come out of this analysis is really just how high-performing or what high-performing IT organizations mean to the bottom line of these companies that are doing it. I think, at some level, we all at a gut level say, “Well, if you’re performing better, you’re releasing faster, it should translate into a better company,” but, certainly, the State of DevOps report—survey and report is one of the few that are out there that really connects the dotted lines here.
Kersten: Absolutely. So you look into the sort of things that people are actually sort of seeing. What we’re seeing, so to sort of hit some of the boon stats from last year, is that we’re seeing the high-performing IT orgs, three times lower change-failure rate, 200 times more frequent deployments, and 24 times faster recovery from failures. And those are really amazing stats because I think they really resonate, both with practitioners who’re the people who are getting woke up in the middle of the night or having to deal with the pain of a deployment that didn’t work properly, but they’re also the sort of stats that your average, been-away-from-the-technology-keyboard for a few years, high-level executive, can look at it and they go, “No, that’s actually what we want. We want to be able to deploy more frequently,” because, I think, one of the lessons that SAS has taught us is the reason a lot of SAS companies outstrip on-premise competitors is because, every time they deploy, it’s a chance for learning, it’s a change for feedback.
And Agile has taught us, from traditional software development, the more frequently you can deploy, the smaller the deltas are in those deployments and you can do more frequent cost correction, so you can actually produce a much better outcome over time by deploying more frequently and being able to correct course more frequently.
And, to, I think, bring it back to enterprise folks, not everyone always thinks about deployments in this way, but, every time you get a patch from your vendor, that’s another deployment. Every time you respond to a security incident internally, every time you have to follow through a recommendation of your audit and compliance committee—all of those things are deployments and the more pain-free and friction-free you can make the ability to deploy within an organization, the more responsive you’re gonna be to all the different stakeholders.
Shimel: Yeah. Let me give you my favorite stat that you omitted or you just didn’t get a chance to, and that is these high-performing IT organizations have 50 percent less vulnerabilities post-deployment.
Kersten: Yep.
Shimel: That’s huge.
Kersten: It’s a major. And you’re spending less time on that. And I think the other related one that’s really amazing is that the high-performers spend 22 percent less time on unplanned work and rework. And, for anyone’s who’s been neck-deep in infrastructure, it’s the unplanned work that kills you. It’s the context switching. You’re not making progress on your defined road map every time you’re having to spend time on unplanned work.
Shimel: Yeah. So, Nigel, these are all fantastic insights and metrics, so now, of course, though, we’ll turn the table on you and say, “Hey, what have you got for us this year?” I know it’s early; I know you haven’t released the report yet. You’ll probably be announcing a lot of the results, I think, come out just at the time of DOES London, which, again, is June 5th and 6th, but is there anything you can share with our audience as maybe a preview?
Kersten: So I think one of the things that I could share is we’re still going through doing the analysis, but we’re seeing that, again, the high-performing orgs are achieving just as well compared to everyone else, as they have in previous years. It doesn’t look like there’s only sort of peak, as far as implementing these practices. I think the whole industry, even people who have been doing this for a while, have still a fair way to improve.
I think one of the really interesting things—well, there’s two big ones I wanna call out. One is that, this year, we spend a bit of time working on non-profit performance ’cause, in previous years, we’ve shown that commercial companies who are high-performing IT orgs tend to outperform their financial metrics, outperform in the stock market, their internal company goals, but, this year, we decided to focus on non-profit performance, and so we’re looking at things like, “What’s their operating efficiency like? Customer satisfaction? Quality of the products that have been shipped?” So we’re actually, I think, showing that DevOps practices in high-performing IT orgs impact in a positive way all sorts of industries, so I think that’s gonna be one of the really interesting sections.
The other section, I think, that’s gonna be really fascinating is that we’re actually looking at what’s the—there’s a myth out there, to sort of back up a little bit, that DevOps practices tend to work if you’re building all of the software yourself, if you’ve got a web app, if you’re building a whole bunch of stuff in Node.js or something like that, and deploying it to the cloud, sure, you can do DevOps—you can do continuous integration; you can do continuous delivery—but, for those of us who are sitting there running commercial, off-the-shelf software, we can’t actually do that and we can’t actually obtain the benefits that are available by employing DevOps practices. So I think what we’re gonna be showing is that this isn’t true, that there’s a couple of things you can do as an organization, in the way you consume commercial, off-the-shelf software, to actually let you employ continuous integration, continuous delivery.
Now the reality is you’re not gonna be able to test all the same kinds of things because, unfortunately, you know, lots of vendors that release software don’t necessarily have an API-first policy, so you’re not always gonna be able to test everything inside the application, like you can’t run unit tests, necessarily, ’cause it’s not your code, but there are a whole bunch of things you can do. And one of the big bits of guidance that we’re gonna be pushing is that, when it comes to commercial, off-the-shelf software, really try to make the installation as vanilla as possible. Don’t spend forever customizing it. And, if you’re having to customize it because that’s what your business processes say, in many ways, the lower-cost and better-outcome approach is to not customize the software and adjust your business processes because there’s something within your control, generally. And if you adjust those, then it becomes simpler to deploy that software into a CI system, to have Jenkins or Bamboo or whatever do deployments of it, do external black-box testing, make sure that it actually works, and then roll it out to production.
So we’ve got a pretty strong belief that, when it comes to utility computing, to sort of use Martin Fowler’s distinction between utility and strategic computing.
Shimel: Yep.
Kersten: There are huge efficiency gains to be made there, but there’s a few things you can do to avoid those problems. The analogy I kind of come back to is that there was a period, I think, in the late ’90s and early 2000s, when lots of people would customize their Apache installs. They would sit there and come up with this fine-grained list of modules, configured in specific ways, and, every time they deployed a new version of Apache, they’d eke out another one or two percent performance by having this really customized installation. It turns out the actual cost to the business is really great because those tend to be manual processes—you’re turning yourself into a snowflake when you didn’t actually need to be—and I think the more you can commoditize the software you’re buying and that you’re building and that you’re deploying, the faster and more friction-free a lot of these processes are gonna be.
Shimel: Got it. You know, Nigel, that—so I’m old. That’s firing up some old synapses in my brain back from the dot-com days, when I helped start a company called “Interliant.” We were an early ASP. And, mind you, this is before we have a modern cloud and virtualization and ubiquitous connectivity, but we were offering hosted Lotus Notes, PeopleSoft, Oracle applications, Lawson ERP—I don’t know if you remember Onyx was an early CRM tool back then.
Kersten: Oh, yeah. Yep.
Shimel: That’s a blast from the past, huh?
Kersten: Totally.
Shimel: Anyway, so our thought was to offer hosted versions of these applications. This is early, right? We called them “application service providers.” And what we quickly learned in—you know, when you go to market, and we did the whole IPO thing, all of that, but what we learned from our enterprise customers was that, as much as we wanted them to run a vanilla PeopleSoft or a vanilla Lawson or Onyx or even Lotus Notes, for that matter, the best we could hope for was about 80 to 85 percent of out-of-the-box, just plug-and-go. They always needed—and so what happened was we had to change our whole business model and we wound up acquiring a bunch of service bodyshops, for lack of a better word, who would come in and do that last-mile customization, if you will, that last 15 percent. And, as a result of that, I will tell you, the business model failed, ultimately bankrupt. And, if you look at all those early ASPs, none of them really succeeded—USinternetworking and Corio, some others—because we weren’t able to get people to use the vanilla configs that would have been easy for us to host, spin up, and put down.
I think you see the same thing a lot today, with kind of bare-metal hosting. Right?
Kersten: Yep.
Shimel: Versus a traditional cloud virtual, you know, kind of hypervisor thing. How many people are using just vanilla bare-metal kind of config versus how many have—and you guys are Puppet, right? You’re dealing with this more than most, right? How many people are highly, highly customizing their bare-metals?
Kersten: I think we’re seeing people shift away from customization. I think there’s probably a few things. One is I think people are realizing that a lot of this industry is sort of commoditizing, and so you may as well use off-the-shelf stuff. And so, if you’re just consuming stuff the way it was sort of shipped from the vendor, whether it be hardware or software, there’s sort of a general expectation that, I think, both software quality has improved—as much as we like to bitch and complain about software, I generally think software has gotten better than it used to be. There was no sort of Golden Age of incredibly rigorous enterprise software, as far as I’m concerned. I think stuff’s getting better. So I think there’s a couple of different pressures there, is that software’s gotten better, people have gotten more used to the idea that various things are being commoditized, and so they’re more willing to entertain the notion that the next layer up is getting commoditized.
Shimel: Yep.
Kersten: I think we’re also seeing things like—so here’s a good example, I think. If you consume Atlassian’s JIRA, the hosted version, versus the on-premise version, you can’t customize it as much. And, if you’re consuming GitHub the public service, versus GitHub enterprise, you can’t customize it as much. And so there’s a general understanding from people that, you know, an uncustomized version, or as much as is sort of possible, is actually pretty good and we don’t need to make everything completely different for everyone else because it means that documentation just works out of the box and people who’ve used the software somewhere else can join the company and have much faster on-ramp.
And I think we’re seeing that—and this is a somewhat optimistic approach—that there’s a general desire for people to adopt software engineering principles and sort of DevOps cultural changes to get to that higher-performing IT organization state. And I genuinely think, if we keep pushing this sort of attitude out to people that, “If you don’t customize your software, adjust business processes to fit instead, that’s cheaper and you’ll get a better outcome,” I think all of those things combined sort of give me hope that we’re actually heading towards a world where people are giving up unnecessary customization.
Shimel: I hope so. But, Nigel, we’re so far off our course here. You know, we were supposed to be talking about DOES London, and let me try to bring you back. So, I mean, obviously, all of this is background and the—this is why this survey is so important, so that we see these trends and we see it manifest itself in how companies are doing things and so forth. Let me ask a little bit—so, Nigel, you’ve presented at DOES before and I did an earlier interview today—I was talking to one of the program committee’s members for London, Jonathan from Hiscox—and –
Kersten: Ah, yes.
Shimel: Yep. And, forgive me, his last name—Jonathan Fletcher from Hiscox.
Kersten: Yeah.
Shimel: You know, and I’ve known Jonathan for some time—great guy. What we—you know, we forget—all rolled into one place in the space of two days, we’re gonna be jam-packed with all of this great information around DevOps and what we’re seeing and not only what we’re seeing but people are gonna talk about what they’re doing right now and what they did last year versus this year versus next year, what the findings are in our surveys, and I think that’s what really makes for a great event. Right? I think –
Kersten: Yeah, I think there’s a couple of things that are really unique about it. I think one is that it’s not a vendor event, and I’m in the business of working the software company and we make and sell software, but it’s also really refreshing to go to an event where everyone who’s on stage is really there just telling case studies, their real-world stories. They’re not product-pitching to you. We’re not getting up and pitching Puppet Enterprise to you at all. We’re getting up and talking about the DevOps report, and everyone who’s there is—I think this is Gene’s big focus, is that everyone’s telling a real-world case study about what they’re actually doing, where the challenges were. It’s war. It’s honest. So I think that’s one section of it, that it’s real stories from out in the field.
But, perhaps more importantly, it’s not just practitioners. And I think those of us who sort of have had a technical background can sometimes get too in the weeds about going and watching someone’s talk about this incredibly interesting deployment they’ve done and what they achieved, but we’re seeing business leaders talking about the actual impact on the business, how they ran large departments, large transformation projects. You know, the term “digital transformation”’s been kicking around for quite a long time, but we tend to see very sanitized case studies, driven either by a software vendor or a large consulting firm or the PR department of some multinational corporation talking about what they’re doing, and these tend to be really warts-and-all stories, going, “This is what we did and this is how it worked or this is how this didn’t work.”
And I think some of those are some of the more fascinating stories, where people are getting up and talking about “Here were our lofty ambitions and we only got 60 percent of the way there and these were the problems we ran into.” And that, I think, is just really, really powerful, so I think the fact that you’ve got senior business leaders and executives there, as well as the fact that they’re all real-world case studies, is just a really, really powerful combination.
Shimel: Yep. I agree with you. As a matter of fact, one of the things I’d love to see is more people get up and talk about failures, right, where maybe DevOps, they didn’t do it right, or what they could have done differently or what have you, where it didn’t work out right and this is what we did as a result, ’cause I think too many people come out of these events, out of Gene’s things, sometimes, and it’s like it’s all rainbows and unicorns and horses and such, and that’s great, but we—you know, as a dad, I try to teach this to my kids—you don’t always win. And that’s why you gotta learn to deal with failure and how to recover from that as well. And I think those are some of the best lessons for people to learn, is we learn more from our failures than from our successes sometimes, so.
Kersten: Absolutely. And I think it’s hard because we haven’t always had a culture in the IT industry of actually performing postmortems and retrospectives on large projects that we’ve done, so it’s people don’t always have great answers for how they would have done things differently, but I think that’s something that’s actually also starting to shift quite considerably. We’re seeing DevOps has been a big part of that, of “Let’s do blameless postmortems,” and, hopefully, that continues so that we see more people being open about their failures.
‘Cause I think one of the things I find really frustrating—this has happened to me more than once and I don’t think this is gonna identify me, one customer or user, because they do so many of them—seeing your executives at Amazon summits get up and talk about how fantastic their whole cloud migration journey has been and that they’re all in the cloud and everything’s done and it’s absolutely wonderful. And then you go talk to the VPs or directors who are actually running those deployments and they’d be like, “Oh, God, no. We’ve only moved five percent of things and it’s been a miserable failure and we’ve now added three years to the project because we’ve fallen over organizational boundaries.” So I think that gap between the sort of PR-style business leader talk and the reality—that’s not a gap that actually exists at the DevOps Enterprise Summits, which I think’s been really fantastic.
Shimel: Yep. Agreed. Agreed. Well, Nigel, our little 15-minute chat has turned into a solid half-hour, and I think we’re gonna need to call a break here. We are looking forward to the release of this year’s analysis of the survey, looking forward to your presentation along with Dr. Nicole at Gene Kim’s DevOps Enterprise Summit in London, June 5th and 6th, and just always looking forward to what you’re up to and what the folks in Puppet are up to. Many people, you know, when they think DevOps, they think of companies like Puppet, right? A leader in—I don’t know if they’re ever gonna do a DevOps Magic Quadrant, but—or some sort of stuff like that, right? But, I mean, seriously, Puppet’s one of the cornerstones here and you’re one of the cornerstones in Puppet, so it’s always great to hear what’s happening from you and getting caught up. It’s a pleasure.
Kersten: Aw, thanks, Alan. So I will get one little pitch in, which is, because of DevOps Enterprise Summit being in London that week, we’re going to be announcing pretty soon that we’ve got a Puppet Camp happening pretty soon afterwards, so there’ll be a Puppet Camp in London, and this will be a slightly different tweak on the Puppet Camp format. We’ve run hundreds and hundreds of these events over the last few years, but we’re doing a slightly different thing, where we’re having a sort of more executive-manager-focused morning and a more practitioner-focused afternoon. So, if you’re someone who’s an IT architect, you might find mornings and afternoons both applicable, but we’re really looking to try and join together the conversation for sort of senior executive leaders as well as practitioners on the ground. So we’re already collecting a whole bunch of really great talks, both for the morning and for the afternoon, but, for those of you who are into Puppet, look out for a Puppet Camp London coming soon after DevOps Enterprise Summit.
Shimel: All right. We’ll try to get info on that up on devopsy.kinsta.cloud for anyone interested. Nigel, fantastic, man. Thank you so much for the time today. We appreciate it. Nigel Kersten of Puppet here on DevOps Chat. This is Alan Shimel for DevOps Chat. Hopefully, we’ll see you soon at the next—on the next DevOps Chat. Until then, have a great day.
Our guest on this DevOps Chat is Jonathan Fletcher, CTO of Hiscox. Jonathan will be quick to tell you that he is actually “interm” CTO. But as I told him in our Chat, if Hiscox is as sharp a company as I think it is, it will make that title permanent soon. I have known Jonathan for about 3 years or so now; I believe it was at a Ranger4 event in London where I met Jonathan. It was readily apparent to me that he was the driving force behind Hiscox’s impressive DevOps transformation.
Jonathan is on the program committee for this years DevOps Enterprise Summit London. We spoke a bit about what it is like to be on the programing committee for DOES. We also spoke about what he is presenting at DOES. You will have to listen or read along to find out.
As usual, the streaming audio is directly beneath, with the transcript of our chat below that. Enjoy!
Audio of our Chat with Jonathan Fletcher
Transcript of the chat with Jonathan Fletcher
Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m very happy to be joined by our guest for this DevOps Chat. It’s Jonathan Fletcher, CTO of Hiscox. Jonathan, welcome to DevOps Chat.
Jonathan Fletcher: Hi, Alan.
Shimel: Great to hear from you, Jonathan. I probably haven’t spoken to you since, oh, maybe DOES London of last year, which was also in late June and –
Fletcher: No, that’s right.
Shimel: Yep. Since that time, looks like you’ve got a new title over at Hiscox. Is that correct?
Fletcher: That’s right. Interim at the moment, but, hopefully, that will develop into a permanent role in the not-too-distant future.
Shimel: Well, if they’re smart, they’ll make you permanent.
Fletcher: A CTO office.
Shimel: Yep. Excellent, John.
Fletcher: Yeah, I think you’re quite right.
Shimel: And well-deserved.
Fletcher: Yeah
Shimel: Well-deserved.
Fletcher: Thank you.
Shimel: So, Jonathan – excuse me – Jonathan, I wanted to speak to you today, though, a little bit about the upcoming DevOps Enterprise Summit London 2017, which is June 5th and 6th, at the QEII Conference Center in London. And you’re actually one of the speakers lined up for the event. That’s correct?
Fletcher: That’s right.
Shimel: And, Jonathan, can you – I don’t know if it’s too early or not, but can you give our audience maybe a little bit of a preview of what you’ll be talking about?
Fletcher: That’s a good question [chuckles] and I’m not sure really sure yet. I think what I’m gonna be talking about is a little about a continuation of our journey, particularly about moving to cloud and what that means, the business results that can be found from doing that, along with sort of where we started and how that changes the IT organization. ‘Cause moving to cloud isn’t just a move of technology; it’s change in skills; it’s a cultural change. It changes things that I hadn’t really thought about, a way we budget, I mean, in fact, from a legal compliance teams. It’s a real transformation program for us. I kind of keep (saying) that savings isn’t IT 1.1; this is IT 2.0. This is a new IT department. So I’m really excited to kind of talk about that. We’ve got a long way to go ourselves, but seen some good early signs with cloud adoption, so I think that’s where I’m gonna focus my time.
Shimel: Fantastic. And, Jonathan, of course, in addition to your speaking role with DOES London, you’re also on the – is it called the “speakers committee”? Is that what it’s called?
Fletcher: Yes, right, programming committee.
Shimel: Programming committee. I’m sorry. Jonathan, can you – our audience, the overwhelming majority of them have not served on the program committee. Can you give us a sense of what is involved in that?
Fletcher: So there are dozens and dozens of people who want to come along and share their story next year, so the program committee really is around trying to filter some of those down – not everyone can come and talk – and trying to make sure they are as much relevant to the audience that’s coming, so I think it was worth reimbursing in last year. it was real stories from people doing transformations at real enterprises, and not unicorns, not ace, but is this a real bank, real insurance company, real companies with a legacy of acquisitions and different types of IT, different technologies, and hearing about how they’ve got on and what they’ve got to do in the future, so that’s really powerful. So program committee’s trying to turn a number of – dozens and dozens of submissions to the program down into a really good, tight sets to deliver over two days in June.
Shimel: I got it. And, Jonathan, I don’t know if you even know the answer, but can you give our audience a sense of how many submissions versus how many speakers are actually selected for an event such as DOES London?
Fletcher: So I’ve seen a bit of pre-filtered list, so I couldn’t speak on Gene’s behalf how many there were, but I’ve seen hundred – in the hundreds, I guess. And I think that’s down to 30-something; again, I don’t wanna get the numbers wrong, get the (incorrect) stats, but it’s significant amounts and significant amounts of people that Gene has conversations with, I guess, _____ _____ _____ _____ get through to a formal submission, so it’s very significant, which I think is a really good thing. Obviously, people are seeing a value in DOES London and wanna come share their stories, so it’s a shame not more people can do it, but it’s only those two days.
Shimel: Yep. Absolutely. You know, and I have some ideas around that I’m gonna talk to Gene about. But, Jonathan, was there any – obviously, the DOES, the Dev-Ops Enterprise Summits, traditionally focus on large organizations, “horses,” as we call them, telling their transformation story. And some of these stories we’ve now seen and followed over multiple years and we’ve seen that transformation evolve. Were there any particular themes or things that the committee wanted to really bring out for this year’s event?
Fletcher: I think it’s lot of different things. I think a – in terms of sense of continuity between last year’s and this year’s, so what are the results that we’ve seen, in terms of transformation and – that seems to be a bit of a theme. To share that continuity _____ _____ years is quite an interesting thing to look at. The theme, obviously, is try and – the _____ tend not to be technically focused, so we don’t have too many groups talking about technology, more about the people and process of things. So I think a lot of what you’ve heard last year, the same kind of thing, but, hopefully, just seeing people a bit further along the journey, where they’re going to and the challenges that they’re running into.
Shimel: So, Jonathan, this – you know, I’m gonna attend this year’s DOES London event, and this will be the, man, the fourth or fifth DOES that I’ll be attending. And, though I think I’ve come to – I think all of us have come to appreciate hearing the transformation stories of these various organizations, bigger picture, in order for DevOps to continue to grow, right, what else needs to come to the forefront at conferences like DOES, other than “Hey, we tried to do this DevOps thing and here’s how we’ve done”? Do you think at some point we need to hear more than that around DevOps?
Fletcher: Sorry, what do you mean?
Shimel: So, in other words, at this point in the game, depending on who you believe and who you listen to, a majority of enterprises have at least dipped their toes in the DevOps pool, if you will. Not many of them have undergone an enterprise-wide transformation, but at least they’ve started along their way. What more – so, in other words, what is there beyond the “We’ve tried to transform the company” type of lessons that the DevOps community needs to learn from these events? Or maybe there is nothing more.
Fletcher: That’s a good question. Well, I don’t know. It’s a difficult question to answer, really, ’cause it depends on the strategic direction for those companies and how far they need to push the barrel. I mean, not everyone needs to release 400 times a day _____ _____. You know, the different companies got different requirements. And I think, really, DevOps is such a all-encompassing term now that it’s kinda lost its meaning. If your company is about improving quality or that’s your strategic goal, rather than the pace of change, there are different things for different people, so dipping your toe in the water is fine. I think DevOps is for everyone, regardless of scale of company, so those focused on enterprise, well, that doesn’t mean that, if you’re a small shop, that’s not relevant to you ’cause it is.
I think, really, it’s such a wide topic that seems to encompass Agile and Lean and technology and people, and it’s so vast in topic that, actually, the next step for people in the transformation program ought to stop worrying so much around necessarily what other companies are doing. The war stories are good, but it’s focusing more on what that really means to your company. It’s no longer about DevOps transformation; it’s about business success transformation and what you need to get to get you there. So I think a bit of maturing thinking from companies that started on this program is really actually what they tried to achieve and where they need to get to because I think there’s an assumption between certainly some people aspect where it’s all about Puppet and getting 4,000 releases out the door, and that’s not always the case. So _____ _____ big business goals and I think really trying to realize some of the results so that the business benefits ’cause we’re doing this not because it’s cool and it’s _____ cool IT; it’s because there’s tangible business benefits in doing it. And I think that’s really what the community needs to focus on and _____ –
Shimel: Yep. And I think you’ve — Jonathan, I think you’ve hit that right on the head and that’s just what I was looking for, which is so many people, especially in the IT industry – I don’t know what it is about the IT industry, but we suffer from “shiny trinket” syndrome, right? Where everyone wants to latch onto what the new cool thing is. And the risk you run is that, when the luster is off of the trinket, people tend to start looking for the next trinket, instead of doing what makes sense for the business, what’s best for the business. You know, ’cause to my mind –
Fletcher: Yeah, exactly.
Shimel: Right?
Fletcher: It becomes a – go ahead. Sorry.
Shimel: No, no, go ahead. I’m listening.
Fletcher: Yeah, it becomes a little bit of a statistics race, like, “How fast can I get a release out the door? How many servers can one person look after?” And, actually, that’s fairly meaningless, unless there’s a business benefit behind it, so that sort of arms race to be the fastest becomes less and less relevant, so. And, as I said, DevOps is such a wide term now that it kind of – it’s just about doing IT better.
Shimel: Yeah. And that’s exactly it. I mean, Jonathan, to me, in my many, many years in IT and in business, there’s very few revolutionary things. There’s more evolutionary type of developments, right? And, when we look at DevOps, we look at the Agile that came before, right, and we see kind of where Agile is and its effect, but yet we still see plenty of organizations that are doing waterfall or some may call it “fast at waterfall” or “Agile waterfall” or whatever you wanna call it. But, you know, it’s a very – the inertia in our systems is such and entropy in our systems is such that nothing moves – we don’t move at the same speed across. And even something like DevOps, though you may have organizations that are now presenting for the third or fourth year at a DevOps Enterprise Summit, there’s still plenty of organizations that are still just starting on that journey, and they will be on that journey for many years going forward. And I think we lose perspective of that when we live in this bubble of “Who’s releasing the most often? Who did this first? Who’s on to the next thing?” That’s not who wins the game, necessarily. People who win the game are organizations –
Fletcher: Well, and –
Shimel: – and their customers. Go ahead. I’m sorry.
Fletcher: And some of these things are – all these things are less relevant, so, if you’ve got a system you’re gonna throw away in two years’ time, there’s – ROI to spend tons of time automating it and putting all that engineering in place with, you know, sort of – is kind of mothballed. So, again, it’s picking the right application, the right teams, to get benefit from this. I don’t necessarily see the – you have _____ all of these other _____ everywhere. Waterfall has its place. It’s about picking what is right for the business and getting the business _____ _____ _____. It’s not about a blanket “This is a right way or this is a wrong way of doing IT.” I just don’t believe that.
Shimel: Mm-hmm. I agree with you. And so, Jonathan, we’ve come full circle in our short little chat, but this is what makes DOES a great conference to attend. Right? Where we are hearing these transformation stories, and some of them may be old hat to some of us, some of it may be a revelation to others. Right? But it’s – the last part of this that I wanted to hit is that it’s, at the end of the day, it’s about the community. We as a collective community learn from each other’s experiences and these shared experiences, and that’s how we evolve and that’s how the whole movement moves forward, not just Hiscox, not just Disney, not just any particular organization, but as an industry, as a movement, that’s how we move forward. And then I think that’s what DOES is about.
Fletcher: Yeah, and that feels fairly unique. I can’t remember, in my 20-odd years of working IT, a movement with such a community feel, with so many people who want to help other people, and it’s – I think that’s amazing. And I don’t ever get – when I speak to people much further down the line than we are and they do better things then we do, I never get that looking down their noses or “You should be where we are.” It does feel like a real community sense of being, that everyone’s gonna help each other. And I don’t know what it is about DevOps, but I think that’s amazing, and you really see that at DOES.
Shimel: Yep. Absolutely. Jonathan, we’re about out of time here – probably, we’re over time – but, listen, I wanna thank you for joining us today on DevOps Chat. I look forward to hearing your presentation at DOES London and we’ll check in before then and get more of a final version of what you’re speaking about. And, also, I wanna thank you for being on the program committee. I’ve been on organizing in program committees of events in the past and I know it’s, in a lot of ways, an unsung job – you don’t get paid for it and God knows there’s ton of work that goes into it – so thank you for your service.
Fletcher: You’re welcome. Thanks very much.
Shimel: No, my pleasure. And, Jonathan, I’ll get together in London beyond that. Maybe we’ll catch up on a video or something. Hey, but continued success. I hope, by the time I see you in June, the interim title’s gone. They couldn’t find a better man or person for that job. All right?
Fletcher: Thanks, Alan.
Shimel: Cheers, Jonathan. Jonathan Fletcher, Hiscox and the program committee at DOES London 2017. This is Alan Shimel for DevOps Chats and devopsy.kinsta.cloud, and we’ll see you on another chat soon.
On the heels of our latest DevOps Enterprise Summit London speaker and programming announcement, I had the pleasure of being joined by Tom Clark, head of Common Platform at ITV;Andrea Hirzle-Yager, head of Department, IT at Allianz Deutschland AG;Mark Schwartz, CIO and author of “The Art of Business Value” and “A Seat at the Table“; and Mayank Prakash, Chief Digital and Information Officer at Department for Work and Pensions for a live video chat—already our third installment for 2017! We huddled up for an hour and took a “deep dive into DevOps,” as my fellow panelists shared keen insights into their technology transformation experiences and leadership lessons learned from pioneering DevOps adoption in their own organizations. And as you’ll find out, these are all such great people!
Clearly, one of the responsibilities of technology leaders in DevOps transformations is enabling a culture of continuous and lifelong learning. In fact, this characteristic is one of the more profound conclusions after having seen nearly 200 leaders share their stories over the past four years. And holy cow, if there’s a great time to learn, it is now; personally, I can’t overstate how much I’ve learned since co-authoring “The Phoenix Project.” (For example, in Dr. Steven Mayner’s DOES16 San Francisco presentation last year, he confirmed that this seems to be a critical element of successful transformation—you can see what we learned about the role creating a culture of learning and transformation plays in successful Agile and DevOps transformations.)
These were among several questions that I had to privilege of asking Andrea, Tom, Mark and Mayank.
What will you be presenting on this year?
What can you share about what’s happened in your own journeys since 2016?
What can you tell us about your DevOps journey and technology transformation?
Can you tell us about where you decided to start, and why you chose there?
It’s been observed that DevOps transformations are easier in smaller organizations—what are the toughest obstacles that you’ve overcome as leaders in your journeys?
What are your favorite lessons learned that you think would be applicable for all leaders endeavor in to do similar things in their organization?
What are your favorite resources you look to (past and present) for leveraging the best practices and principles—this could be in the form of research, books, events, articles, etc.
Can you share you impressions of your two days at DevOps Enterprise Summit London last year?
It was fantastic hearing the specific lessons they’ve learned in their journeys that they thought would be applicable for all leaders doing similar things in their own organizations. It was interesting to hear how books and conferences play such a critical role for them, as it has for me—and I always love getting a glimpse of the bookshelves of technology leaders, because certain books keep keep showing up up again and again
Be sure to watch the video replay of the chat—there are some great nuggets of information about where these leaders are in their own transformation journeys and what you as DevOps Enterprise Summit attendees can expect at the event this June.
DevOps Enterprise Summit London Update
Plenty has happened since our previous live video chat with Jonathan Fletcher, Cornelia Davis and Jonathan Smart. The programming committee has made its final selection of speakers to round out the conference program, and we’re in the final planning stages for the event this June. One item on the agenda that I am particularly excited about is the “Ask the Speaker” portion of the program. This year, we are opening up an hour of time each day of the conference for question and answer sessions between our plenary speakers and conference attendees. It’s going to be a great way for attendees to pick the brains of the folks just coming off of the main stage.
Additionally, we have added another format (tested during DevOps Enterprise Summit San Francisco last year) that we called “DevOps Workshops.” These are small-group discussions using the Lean Coffee format, with a small army of trained facilitators at each table.
We’re expecting a phenomenal turnout for each of these sessions and we’ll have some world-class people helping to lead the discussions. More to come on that soon!
Want to join us in London this June? Save 20% on tickets using code “DEEPDIVE20” today!
As adult learners and leaders, we tend to glean less from theory and seem to derive more from people actually describing the real-world problems they are trying to solve. Ever since the DevOps Enterprise Summit began in 2014, we’ve been adamant about providing a unique venue for the technology leaders of large, complex organizations to come together and share their DevOps transformation experiences—from how they started and what they did, to what the outcomes were and what they learned.
On the second video chat gearing up for DevOps Enterprise Summit London 2017, programming committee members Cornelia Davis (Pivotal), Jonathan Fletcher (Hiscox) and Jonathan Smart (Barclays) joined Gene Kim and spent an hour taking a “deep dive into DevOps,” to reflect on the first DevOps Enterprise Summit London last year. Panelists also shared some of their lessons learned and wisdom about their own DevOps transformation stories today and shared some of their favorite resources for leveraging best practices and principles while discussing the value of lifelong learning.
Just a reminder that Early Bird ticket pricing for DevOps Enterprise Summit London 2017 was extended to 22 March and the price is only £650+VAT. Register here >>>
All in all, it was an excellent conversation with Jonathan Smart, Cornelia Davis, Jonathan Fletcher, and Gene Kim as we all inch closer to the DevOps Enterprise Summit London this June. The goal (according to each of these people who are now on the programming committee for London) is to hopefully make the show even better than it was last year. We look forward to seeing all of you June 5-6 at the QEII Conference Centre.
Here is the video and a full transcript of the conversation below that. More links to DOES videos and interviews are down at the bottom. See you London June 5-6!
Gene: Summit 2017 in London. This conference is taking place on June 5th and June 6th. For more information on this, just go to events.itrevolution.com. I think what excites me so much about the DevOps Enterprise Summits is that there is just, no doubt in my mind, that the people who are presenting are the leaders and practitioners, who are pioneering how we’re managing and using technology in large, complex organizations. So on this Live Chat, we have Jon Smart from Barclays. We have Jonathan Fletcher from Hiscox, Cornelia Davis from Pivotal who’s also…In fact everybody is on the programming committee.
So my goal next hour is to have each one of you share what you’ve been working on, share some of your lessons learned and wisdom which is just, obviously, a fraction of what you’ll be presenting at the DevOps Enterprise Summit. So just one last reminder is that there’s an early bird ticket pricing that ends on the 8th of March, which is one week from today. So the next step is really to share what wonderful speakers that we have on the panel today. So let’s go around the table, and if each one of you could present your name, your role, company and, specifically what you presented on last year. Cornelia, why don’t we start with you?
Cornelia: Sure. Good morning, good afternoon, everyone, and, hi, Gene, and my fellow panelists. My name is Cornelia Davis. I am the Senior Director of Technology at Pivotal, and so Pivotal is a company that maybe is most well known for incubating the Open Source Cloud Foundry Project, and my role is that I work in the product organization. I work with clients and customers to take our products and use them effectively. Well, it turns out that our products are really disruptive.
It’s very different architecture and so they have to change everything. So that’s where DevOps and digital transformation comes in, is they actually have to in order to use our products effectively, they have to change organizational structures and you have to change processes. And I have this tremendous opportunity to work with very large enterprises across the globe, in then figuring out how that works for them.
Gene: It often can be very disruptive to the way we’ve done the thing for decades, absolutely.
Cornelia: Oh, yes.
Gene: Jonathan Fletcher, why don’t we start with you? I wanna go to you next and, by the way, congratulations. I hope you’re gonna tell us about your promotion, as well.
Jonathan: Yeah, so I’m Jon Fletcher. I am the interim CTO for Hiscox Insurance. Based out of offices around the world. I’ve been the CTO for a month, five minutes, it seems. So, it’s fairly new.
[Crosstalk]
Gene: Can we stand by a second? We’re having some audio issues. Let’s go to Jon Smart while we resolve that. Jon?
Jon: Hi, Jonathan Smart. So I work at Barclays. My role is Head of Development Services and I’m leading on better products faster, so better ways of working, adoption of agile dev ops, lean principles, and practices across Barclays.
Gene: Brilliant, and what did you present on last year?
Jon: Last year, I presented an Experience Report. So I gave an update of the Barclays journey across the whole organization. We started two years and two months ago, beginning in 2015, so last year, I gave an Experience Report, shared some of the lessons we’ve learned in terms of transforming a large organization. We are 130,000 people in 40 countries. We have 48 million customers.
We’ve got some main business lines such as the investment bank, retail bank, wealth, corporate. So we’re a very large organization, as I said. We’re 327-years-old, founded in 1690. Four years before the Bank of England existed so that’s a lot of legacy to change and it’s a large organization. So I shared our journey so far, and I’m looking forward to sharing an update this year, as well.
Gene: Brilliant. And I think one of the things that just left such an impression on me was just the scope of what you’ve been overseeing in terms of how many engineers and how many applications?
Jon: It’s 26,000 staff in technology and over 3000 applications.
Gene: That’s awesome, fantastic. Thank you, Jon. All right, Jonathan Fletcher, let’s go to you. Name, company role and what you presented last year, and you’re gonna to tell us about your promotion. And then we’ve gotta unmute.
Jonathan: I am the interim CTO of Hiscox Insurance. I’ve been in that position for about a month. So I’m not exactly seasoned, but I’m doing it so far. I’m really excited to be part of this and speaking in DOES in June. So I’m looking forward to that.
Gene: Awesome. And then you presented last year?
Jonathan: I did, yes. Sometimes it’s on our move to DevOps and a bit of my personal journey starting as a solution architect four or five years ago, and how I got involved, and how the whole thing started to happen, and I hope this year to carry on talking about that journey and where we are now.
Gene: Very good. Thank you. So why don’t we go to a little bit about the conference and your impressions on it? You know one of the things that many people have told me over the years is that DevOps Enterprise Summit is structured differently than most typical technology conferences that we go to. And I think many of us are, actually almost professional conference attendees. Would you mind sharing your impressions of your two days at the DevOps Enterprise Summit, London, last year? Jon, why don’t we start with you?
Jon: So what I really like about it is that it’s peer-based, so it’s people who are doing the job of transforming organizations and that’s what I like about it. It’s people sharing case studies, sharing their real experience so, you’re learning firsthand. It isn’t a series of sales pitches. It’s about people who are doing the job. Specifically in the horse is not the unicorns. I’m shy of horses, rather than the unicorns. People who are not born Agile, but are born Waterfall. So that’s what I like about it.
It has great networking opportunities, as well, with people who are going through the same journey. And also it’s interesting when you sit through a number of the case studies, you start to see the common themes emerging, and pretty much every single time, the main theme that emerges is it’s all about people. And often with DevOps people jump straight to the tooling and they don’t think about people and culture, often, but it’s all about people. So it’s great when you see these themes coming across from many different companies.
Gene: That’s awesome, and I’ll maybe just comment on that. I mean I think that’s one of the reasons that we choose very deliberately to have people share Experience Reports. Just because as adult learners, as leaders, we tend to learn less from theory. Instead, we learn from people actually describing the problem they’re trying to solve, what they did, where they started, what were the outcomes, and what did they learn. Jonathan, how about you?
Jonathan: I’d echo much of what Jon said, actually. So I like the fact that the very little of it is technical. So very people, focus, culture, process-based and I love being the least smartest person in the room. So it’s watching to learn from lots of other people. I think lots of DevOps conferences are very technical, although, they’re very at the beginning of the journey.
So being surrounded by other people that are at least where we are, if not further ahead. For me, it was a great learning opportunity and I can remember coming away reinvigorated about what we’re doing, and I guess hiring because you were pushing against people that, necessarily aren’t aligned to your way of thinking. So it’s just to get that we are doing the right thing, and we are going the right direction. That was really fantastic. So I really enjoyed those couple days.
Gene: Awesome. Cornelia.
Cornelia: Yeah, it’s all of those themes, but there’s some interesting…As you know, Gene, I work with you on the Programming Committee, have been in the U.S., and now this year in London, as well. I wasn’t at London last year, but we did something in the U.S. last year that we’re going to bring to London this year, and it’s really just an exemplar of what we’re talking about here. It’s a programmatic way of really fostering that peer-to-peer collaboration.
And so last year in the U.S., we did these lean coffees where we had this structured format where we got people together at round tables and had kind of a facilitated way of sharing ideas, and it was fantastic that the tables that I sat at, it was literally an hour-long period. And I think everybody at the table got three concrete takeaways of, “Oh, that’s a technique that I wanna try.” And so as you know, Gene, we’re talking about bringing that type of a format.
It’s not just conference sessions. It’s that type of a format to really foster that collaboration and that’s really very different from a lot of conferences these days.
Gene: Yeah, and I think both Jonathan and Jon will be joining the Program Committee starting this Friday. And I think one of our goals is, you know how do you create the conditions where those serendipitous interactions, how do you maximize the opportunities for the interactions that lead to learning, right? And part of that from a program perspective is we do both the talks, but also creating session formats like that. So one of the things that I’m just delighted about is that the conference will be featuring both Jonathan and Jon, again, sharing the continuation of the journey both at Hiscox and at Barclays.
What I love about this is it’s something that most conferences actually don’t…it’s actually quite unusual, right. But, for me, it seems like this incredible opportunity where we’re almost documentary filmmakers following these leaders, as they go through their own journey and we get to learn as they learn. So you’ll both be presenting for the second time. What can you tell us about what’s happened in your own respective journeys since you presented in 2016? Jonathan, why don’t we start with you about the Hiscox journey?
Jonathan: So last year, I talked about our starts with DevOps, and I guess the point of my talk was that I don’t think we’re really doing DevOps. We’re doing bits of Agile, and continuous delivery, but I think that’s really what DevOps is trying to solve. So there’s lots of stuff with testing in automation and application teams, but really I think the real nirvana is when we bring the Ops side into the equation. So in the last year, we’ve been doing a lot of stuff with cloud.
We’ve been doing a lot of stuff with talking around how we move to a more Agile operations team, rather than a sort of ticket-based system and doing projects in a Waterfall way. So trying to get some of those concepts that we’ve learned in an application mode into the operations teams, and the challenges of doing that, and how we get those two linked together so we can minimize and help the flow of feedback that goes through development into operations systems. This is the final bit of that journey, I guess.
Gene: And you could you talk a little bit about how the change in your role, maybe even going back, I mean how do you think the work that you did in terms of pioneering some of those practices at Hiscox, how did that lead to your change in responsibilities, and how does your change in responsibilities allow you to do more or less going forward?
Jonathan: So I started as a Solution Architect. So actually nothing to do with DevOps at all, and it was kind of just was born out of frustration. I was like, “We’ve gotta change the way we do stuff because this is daft.” So it’s coming in with a great new focus which, again, most DevOps translation started quite small which we got an application, and we did some automation around it, in terms of scale and CD and some automated testing. And then we saw these successes of that and went towards something else, and then it’s just kind of ballooned over the years. And, I guess, we’re really starting to see some of the business payback for that and that’s helped me.
I get more visibility to be seen as someone that’s trying to be more strategic, in terms of how as an insurance company we maintain a competitive advantage. And I think that this step to CTO is sort of the logical conclusion is to help to see that journey through. It’s helped me because now I’ve got a lot of guys rather than influencing up the chain over time, but other peers of mine are direct reports so that that’s gonna help…not that it’s a dictatorship. But it’s going to help my influence and ability to do that, as well as having own budgets and ability to spend some money on that.
Gene: By the way, conclusion sounds so terminal, Jonathan. Let’s not hope that’s the conclusion…haha!
[Crosstalk]
Gene: A continuation perhaps.
Jonathan: A continuation, yes!
Cornelia: I love what you said about Agile operations team instead of tickets. So instead of tickets, it’s so huge. It’s such an important part of DevOps, and it’s all about empowerment, right, but empowerment still in a safe environment.
Jonathan: Yeah, absolutely. I love that. And I think there’s a technology problem there as well. I think it’s very difficult to align the types of tooling that develop as you’re using along with the ops guys that also want to have things like, ITIL based processes and a change management database, and trying to get that transparency across the whole value stream is quite difficult. So that’s one thing I’m kind of wrestling with at the moment.
Gene: That’s great. Jon, how about you? Yeah, what has changed in your journey since you presented back in June?
Jon: So knowing why you’re doing this is important. So why is any company doing DevOps, adopting DevOps and why are active products faster with delighted customers and colleagues, better, faster, happier, safer? And so taking a broader definition of DevOps, in terms of better product, faster, safer, happier we’ve increased our adoption across the organization. As I said, we’ve been doing this across the whole firm for two years and two months.
If you go back two years and two months, it was a relatively small percentage of our change work was done with these practices and principles, and now we’ve got a fairly significant percentage of our change work now being done with Agile and DevOps and Lean principles. So in 2016, we’ve carried on that at-scale adoption, and we have done it apace. We have something like, rough order of magnitude, something like 15,000 people who are now working with Agile and Lean principles, and practices who weren’t two years ago and important to get the ball rolling.
It’s important that we do it with control in a highly regulated environment where as we know the impact of attitude is significant. And so we’ve also been focusing on control because we want both speed and control. Sometimes people might think that you can’t have both speed and control and people might think that speed is at the cost of control, but actually, it’s quite the opposite. You can do anything badly. You can do fragile or you can do Agile, and actually an Agile approach and a lean approach increases control. So we’ve been putting quite a lot of effort in 2016 into control, as to both we are balancing by speed and control.
Gene: Cornelia, you had a question for Jon.
Cornelia: Yeah, I do. So, I thought it was very interesting that you said it’s been two years and two months. So that’s a pretty specific date/time period. What was the catalyst? What was the starting point? What defines as two years, two months as opposed to roughly two years ago? Was there a specific event?
Jon: Well, maybe I’m speaking from my personal perspective. It’s roughly two years. It’s roughly two and a half years and, specifically, what any organization needs to do this successfully, it needs both top down and bottom up. So the specific event, this was a catalyst, in our case is with new leadership and new leadership saying, “Agile and lean is the way to go,” and then the natural champions in the organization, like myself, we put our hands up, “We volunteer to help move the needle.”
Gene: Okay. I mean so in other words, this signal of support from upper management is kinda what you mark as the real start of the journey, right, where it was now a sanctioned, important activity.
Jon: And it was articulated, formally as part of our strategy, yes.
Cornelia: And that is something that I see across, again because I get to see across a lot of different enterprises that are all on a similar journey and that’s not at all unusual. When we have new leadership that comes in, sometimes new leadership that’s brought in, specifically to shake things up, that is often kind of the defining moment where things start to change.
Jon: Yeah, and like I said, absolutely, mandatory criteria to be successful across and organization, you’ve got to have that top down support, as well as the bottom up community. You’re gotta have those two things.
Gene: By the way, I love the number that you put out, in terms of 15,000 engineers working with Agile principles, just to calibrate. That’s actually the size of the Google engineering organization in 2013. So it’s just amazing to see what happens when you can elevate the productivity of engineers that it’d impact that many people. Jonathan, you had a thought.
Jonathan: Yeah, Jon, I was really interested, you were talking about control. Barclays is a fairly massive beast. I was thinking with your move to Agile. How did you have that control at the scale that you’re operating in? I mean lots of Agile teams work very much, almost as a silo, themselves. They’re in back of their work how to orchestrate such a large transformation in such a large company.
Jon: The main principle has been to start with what we have now. So we clearly are operating in a highly regulated environment. We’re not starting from a clean sheet and working towards what we have. We’re starting with what we have and we’re iterating to improve control effectiveness. A starting point was a Waterfall lifecycle, and I’ve spoken about this at the last DevOps Enterprise Summit. We had NT8 mandatory artifacts, many hundreds of questions, and it was a very un-lean process, and it was evolved over time, multiple input, probably from multiple audits and multiple control findings, and so on.
But it became really catered to the lowest common denominator, but applied to everybody. So what we’ve been working on is improving the control effectiveness and leaning the process. So it’s more as a greater risk sensitivity now. So if you’re doing something which is, say, for example, an internal system, nothing to do with payments, no client data, it’s purely…I dunno…a seating map, for example, then it’s risk sensitive. So the controls that will apply to that are in line with our control framework.
Something that is to do with payments, some has client data, the control implications are much higher. The main thing is it isn’t a lowest common denominator for everybody. The thing is applying Agile principles, we’ve moved it to be more of an early and often conversation with our control professionals. So, previously in a traditional manner, you deliver something and we had a control engagement at the end, just before you’re about to put it into production.
And then that leads to another three months to six months of unplanned work, in a reactive manner is what we observed in some cases. So instead we’ve got long-lived controlled tribes, multi-disciplinary long-lived association with the customer value stream, and then you have a conversation at the beginning, and you have regular small conversations as you go, so there’s no surprise at the end. And there isn’t an end because it’s a long-lived product with regular deliverables.
Gene: That coincides with the regular audits that happened, right, the compliance reports. That makes a lot of sense.
Jon: Exactly, exactly. Exactly, the control effectiveness is stronger because you’ve got that regular interaction and the regular looking at an actual product that you’ve actually got something tangible to look at.
Gene: Just as a little side note that we have a group and, hopefully, you’ll be joining us, Jon, from MarkSoft, Capital One, and others, just really trying to help bridge that gap with compliance professionals using their terminology, using the design control effectiveness language, really to show that you know DevOps people aren’t crazy. In fact, you end up with better control effectiveness working all the time. So that’ll be a very fun interaction. I’m very excited about that deliverable.
Jonathan, one of the themes that have come up here is that wonderful things happen when you’re surrounded by fellow travelers who are facing the similar types of challenges and kind of the learning that can ensue. I actually had the privilege of observing one of those sessions that you and I were talking in, and you had a conversation with Scott Prugh who’s the VP of Development and Product Operations at CSG. They’re one of the largest bill printing companies in the United States, and the topic was how do you overcome some of the traditional challenges, how you get more traditional IT operations organizations on board. Can you share some of the challenges that you’re grappling with and some of the insights that came out of that conversation because it was absolutely amazing to observe?
Jonathan: Yeah. So in terms of our org structure, Hiscox a fairly federated business. So we have a number of British units aligned to countries around the world. Application testing teams tend to be aligned to their business units, but operations infrastructure is a group resource that delivers against all of those operations, all those departments. So what we’ve been wrestling with really is how do we or do we maintain that? Do we align infrastructure operation teams to a particular country or do we continue to measure out of a group resource? And if we do that, then how on earth do we have a backlog where we’ve got so many different stakeholders with different requirements, different projects?
And how do we prioritize amongst all those different business units and how do we still get projects done? How do we still get BAU done? I guess the questions that any Agile team has, it’s just on a much grander scale. So each business unit is operating independently. I don’t really care what some of the other business units are doing as much as it’s about their P&L. They want to first bust at the cherry. So does that mean then that BAU goes off to the side and we stop patching because there’s continued focus on projects? So there’s some of the sorta challenges we usually went over with Scott.
Gene: Yeah, mute button. And what was just some of the insights that you had or at least, maybe even validations of the problem? Specifically, how do they inform your thinking?
Jonathan: So I think what was quite interesting is listening to Scott’s talking about visibility of work in progress. And some of the frustrations there are between development operations is because both of them are almost black boxes. So a developer might say, “Look, I need an environment and it might go into a ticket system” and it goes from the server guy towards the SAN guy, and the storage guy, and it goes around in little circles.
How can we let the developers know what the ops guys are up to, and conversely, how do we let the ops guys know what developers are doing? So how do we get that work-in-progress highly visible and that, as a starting place, would be a good way of beginning to address some of the prioritization issues because they’re working off completely different backlogs. The left-hand does not know what the right hand’s doing. How do we start to make that happen? So that was a good sorta first head’s up from him, just to go and look at that problem.
Gene: All right, in fact, I think he’s spoken a lot about trying to get more and more of the ops work into the same work systems as development. So in their case, it would JIRA, and so forth, and less the remedy and so forth, right, just to have a single prioritized work unit.
Jonathan: Yes, but that’s pretty hard. And who’s gonna be a natural tendency for projects to trump everything else because that’s what a business is asking you to do and we’ve gotta change out the door? But you still need to make sure things are patched, and security’s done, and I really like that sort of conversation where you start to allocate points in a sprint, so that’s BAU and that’s projects. If you don’t do that it becomes a very difficult way to triage and prioritize stuff that’s coming because like BAU is gonna be on a loser.
Gene: Cornelia, as coming from a development background, I think you’ve observed something very similar in your journey.
Cornelia: Absolutely. And one of the things that’s really interesting that we found very effective is to take the same product-oriented mindset that the application teams have when they’re building and delivering their products, and actually have that same mindset at the operations and at the platform level. So that, instead of it being treated as just unplanned work, work that comes along, now it comes in, we have to prioritize it, they start to treat their offerings as products themselves. So that they do things like measure…they have a backlog of additional features that they wanna create.
They have release notes that say, “Hey. We’re patching the system on this day” or “You have the opportunity to apply your patches because the patches are queued up and ready to go.” And so really shifting that product mindset, all the way deep down into what’s kind of traditionally an infrastructure kind of role that tends to be a little bit more order cook-ish, and really transforming that into a menu-driven, “Here are the offerings that we have.” Of course, you can’t get rid of all of it, but that’s really, really powerful, is a product oriented mindset, even at that deep infrastructure level.
Jonathan: I think you’re entirely right. I think the mindset, yes, I think the practical application is more difficult. So if you build an environment, for example, you need a server person and a SAN person, and a storage person, and there are lots of techology-silos. So what isn’t very practical is go and take all of those resources, and go and stick them in a dev team because your Agile team’s gonna be 400-people strong all of a sudden which is not ideal. So I think I get the mindset implication or, I think, the technical implementation of that, I think is a bit harder.
Cornelia: Yep.
Gene: Jon, I can’t imagine that somehow Barclays is exempt from some of these issues, as well. I’m guessing that this has relevance, at least in some areas of the organization for you.
Jon: Yeah, absolutely. This really resonates. I think if you go back and my own personal experience, you go back about 20 years ago and, specifically, that’s when banking, we used to do all the roles. I was a developer. I did the analysis. I did the development. I did the support, and I sat next to the customer or the partner and we did everything, and over time, we’ve gone from a role specialization and the split between kinda ops, run, and build, dev. And so, yes, this absolutely resonates.
Generally, for Barclays, coming from a generally Waterfall approach prior to two years ago with islands of Agile, I’m looking at this topic, we’re looking at how we get closer to you build it, you run it. But still maintaining regulatory compliance around segregation of duties, Sarbanes-Oxley Compliance. But as we’ve discussed, the run specialists, the operational specialists, utter the feedback with the build and the dev specialists need to all be lined up behind the customer. And, obviously, what happens when you’ve got operations, you’ve got run who are working in their own world.
The feedback loop never gets back to the dev team, so developers need to feel the pain. I like the SRE Site Reliability engineering philosophy of hiring engineers into ops roles because when you put engineers into op roles, things tend to get fixed kind of at the root cause, rather than a band-aid, rather than a short-term fix. So we are absolutely this is a high priority for us, especially in 2017 to try to increase the feedback, and get more to being one team. But to Jonathan’s point here, we can’t do that with everybody in every role. So yeah, there’s going to be the product teams and there’s going to be secondary teams, and that’s absolutely something we’re trying to move the needle on.
Gene: Jonathan.
Jonathan: Yeah, I think when you start, I think, cloud for us changes that. When the infrastructure guys start to use the same processes, and tooling, and approaches that the developers do, then I think that becomes a lot easier. So I’m trying re-push infrastructure as code at the moment, and I think that is the way of really breaking it down. If infrastructure is just another software project, that becomes really easy to put into that Agile team with the application team. If you’ve got a mix of traditional, “I’ve gotta go and plug a server into a wall. Then I’ve gotta go and configure this” that doesn’t really fit in with a normal Agile team.
And you’ve got a guy was talking to me earlier, he wants to order new servers, six to eight weeks, and then we’ve gotta go and get finance approval for it and. “I think I’ll do this.” That’s not gonna fit in that tight feedback loop that Agile’s trying to work with. So, for me, it’s about transitioning some of the infrastructure skills into more software-led skills, and that’s where you’re gonna get that much closer alignment. That’s where you’re gonna get the DevOps cultural start. That’s where it is. I think trying to do in on-prem, in a manual way is kinda of a bit of a recipe for disaster.
Gene: I think the best people that really embody this is Jason Cox from Disney. His title is Senior Director of Systems Engineering at Disney and he’s talked tirelessly about how he’s tried to create, embed those ops, talent and engineers into the lines of business, into the dev teams, really helping them do things on-demand, and it’s been amazing to see his own journey over the last four years. Just a little joke here.
You talk about infrastructure is code, Jonathan, I love how Scott Prugh from CSG, he said, “The ops of that is infrastructure’s tickets” which is actually what we don’t want, right. We want those on demand. Let’s go to Jon, and one of the just tantalizing pieces that you had talked with us there at Prep Call, just before this panel was the Lean Portfolio Management work that you’ve been doing and how that’s become your newer areas of focus, and I think all our ears perked up about that.
Because of I think this realization that all of us have had over the years, is that you can have fast iteration loops within the dev test operations stream, but if you have an annual budgeting cycle and annual planning process, that really sets some very hard limits on how Agile you can be. Tell us about what you’ve been working on.
Jon: Yeah. So, as you say, we can have as much agility as we like. We can be practicing DevOps. We can have great continuance delivery, but it’s a local optimization when you look at the system, think a system’s thinking and a theory of constraints to deliver better products faster and with delighted customers and colleagues, it’s gotta be end-to-end agility. And so I think this is a natural evolutionary thing, having made some pretty progress, I think in the last couple of years, in terms of how we do what we do.
As we start to expand out in the theory of constraints, look at what the next constraint is. As a large, complex organization, we’re starting from the position of annual planning and annual budgeting, and that doesn’t give us enterprise flexibility as much as we would like. So this is a focus for 2017 for us, is to move to more of a courtly rolling wave type approach, more of a hypothesis-driven investment approach, more of a focus around outcomes, not a predictive plan. So once a quarter you said, “This investment should have achieved these outcomes. Has it?” And being able to build more agility into the system of work holistically.
Gene: Yeah, Jon, I’m dying to ask you. So I think the way I was trained there’s kind of two planning processes, right? You have the project budgets, right, which are owned by the business which tend to be…they can go up and down quite quickly. Whereas then you have the annual shared services budgets, right, where you tax every person, right, 2% of revenue or whatever, and then you a create work queue that’s prioritized, and maybe it’s not a good year now, maybe you’ll get it next year or the year after. So has your focus been primarily on the project on the business side? To what extent can you translate that to shared services?
Jon: So, that’s a good question and I think a caveat to what I said, as a public-listed company, we will still have an annual process. What we’re trying to do is we’re trying to push the courtly rolling wave, portfolio-management process as far…We’ll start at a certain point in the organization and then we’ll try to push it as far up the organization as we can. So that, basically, within our budgetary constraint whether it’s a business investment, you used the word project, whether it’s a business investment or whether it’s a shared service, irrespective of that, you treat it, your budgetary constraint, it is a constraint, and you wanna maximize the value on it.
So you would do it, you know my view is that we do it in both because, as well as about financial flexibility and being about to move money around, it’s also about de-risking delivery and getting away from the sum cost fallacy for a shared service. You know, “You said you’re gonna achieve this and, of course, this year, here’s this big chunk of money.” Naturally, “Have you achieved it? Are you going to slowly?” You know, “Can you cut the value chain? Have you delivered your value? Can you stop early? Can you pivot?” So it kinda serves multiple purposes.
Gene: Just a joke. I mean I was actually having a startling conversation with a friend of mine who was saying that they’re a publicly traded company and there was this sorta zombie operations project that they had depreciated over five years, and they couldn’t kill it because that would actually create a material change in the financial statements. But everybody knew that such a $7 million in a right world, we should just admit that it didn’t work. Kill it, so we don’t have to prop up this fallacy of a services actually running when it is not running at all. Does that resonate at all with you?
Jon: Yeah, it does. You know what we’re trying to avoid happening is exactly that kind of that sum cost fallacy and looking at a traditional approach, I’m sure we’ve all seen large initiatives which have that got multi-year sum cost fallacy that hasn’t delivered, but we’ve already spent so much money on it, we’re gonna carry on spending money on it.
Gene: Just to add color to that story. So they actually had this annual ritual where they’d have to run one transaction through it, just to prove to the compliance people that it is still operating, and so therefore, still eligible to be depreciated which is a shame. Jonathan Fletcher.
Jonathan: Jon, I love what you’re trying to do with that. It sounds fantastic. My question to you is are you forever stuck in writing businesses cases for return on investment? Does that slow the process down?
Jon: Hopefully not. You know we’re taking a lean canvas approach. So it’s not in the past in a traditional approach, you might have had to fill in a PID project initiation document which might be multiple pages long. We’re trying to keep it lean, so we’ve got a one-pager, lean canvas. You’ve got all of the information you need on that one-pager. Again, it’s conversation over contracts. That should be sufficient to have the conversation in terms of, “Do we feel this is the right way to go?” You know we might need to see more evidence. We might need to see more feedback from a proof of concept or experimentation or a customer focus group. We’re trying to keep it lean with this one-page lean canvas.
Jonathan: And is there a maximum budget that you would go with that project? Would you spend a $100 million on a one-pager?
Jon: We have a tiered approach and the tiering is the seniority of the people making the decision.
Gene: Conversations over contracts. I love it. So I’d love to know from each one of you, what are the favorite resources that you go to for finding your inspirations, practices, principles? I imagine this could be in the form of books, events, articles, research. Jonathan, would you mind sharing kinda what books are you reading these days that you’re finding most useful in your own daily work?
Jonathan: You looking for a plug, aren’t you Gene?
Gene: No.
Jonathan: All this here is homework. I think conversations of this kind of thing helps me immeasurably. So there’s this stuff you can get in theory, but it’s real world, practical, “I did this and it failed, and I could have approached it differently.” That’s where I get a load of value and I think just talking to people and getting out into the community. The DevOps community’s great at sharing information. Unlike like any other part of the [inaudible]. So I think people are always really generous with their time. So, for me, it’s not about reading papers. It’s about talking to like-minded individuals and the ones that are honest and go, “You know what? We tried that and it was a terrible mistake. Don’t go down that route.” That’s of much more benefit to me.
Gene: Great. Cornelia?
Cornelia: Yeah. I think a reason that Jonathan makes that point, and I can’t argue against that, is that we are still as an industry pretty early on in this journey. And somebody brought ITIL earlier and sometimes ITIL kinda gets a bad rap. But the reality is that ITIL is something that emerged over years, decades as kind of the codification of the best practices that we knew at the time. And when I was in college I learned about the Waterfall Methodology. That was the best practice at the time so, I’m dating myself, right?
Thirty years ago, in Computer Science Education, they taught us about the Waterfall Methodology and that was the state of the art. We created all sorts of practices around that. We created the books, the standards, and so on, and so we had a bunch of resources to go to. So when somebody was setting up an IT organization or evolving it, they had the manuals to go to and say, “Ah, here’s the codification of the best practices of the day.” Well, I think we’re still so early in the DevOps journey, not super early days because we’re seeing these fantastic success stories, but we don’t have the ITIL of the next generation yet.
So it’s hard to say that this is the go-to manual, this is the Bible. It is really about events like this, and it’s about, I, personally, I’m somebody who, when I’m on the treadmill in the morning, I watch videos, and I’m a propeller head, so I watch a lot of the tech videos, you know purely tech videos, but I watch the videos from previous events. Those things are incredibly insightful and really useful.
The DevOps Enterprise Summit, obviously, is just a fantastic event, but then there’s also what I consider more the grassroots events, like the DevOps Days which are not quite as focused on strategy, but definitely are focused on sometimes very pragmatic, very specific techniques and tools that are being leveraged. You need to bring that together with the high-level strategies. So it’s really still the community, but the good thing is that there’s lots of places to engage in that community.
Gene: Awesome. Jon, how about you?
Jon: So I think what Cornelia said that really resonates in terms of being early days, it’s not early days for Agile and Lean principles, at least in the 1980s, if not earlier, however, what we are learning is doing it to scale, and it’s been at the team level. It’s known at the team level. It’s not known at the enterprise level and so this is where a lot of the learning is. It’s, “How do you do this at scale?” And I’m not referring to scaling frameworks, necessarily. It’s more messy than that. It’s culture change. It’s behavior change. It’s involving everybody in the value stream. It’s not just technology.
Just technology is a local optimization. It’s everybody in the value stream, and we are learning, and this is a new way of working. This is a fundamentally new way of working for organizations with tech or without tech. I don’t know if this right term, but it’s like the fourth Industrial Revolution. We’re going from a tailor-ist way of working from the Industrial Revolution to not just a handful of firms working with multidisciplinary teams with long-lived products, and long-lived value chains, and fast feedback and fast learning, but entire organizations, and entire organizations trying to change how they do HR, how they audit, how they control, how they do portfolio management is a part of that, but it is a part of it.
So we’re absolutely early days. It’s a new way of working. It’s a more engaging way of working. It’s a happier way of working, and at things like the DevOps Enterprise Summit is where we come together to share on this learning. You know the question was, your question Gene was, “Favorite resources for learning…” so another really good forum which is quite similar which is around peers sharing is the SD Learning Consortium, sdlearningconsortium.org and it’s a community. It’s not commercial and we have a number of large companies sharing this journey and that’s where I get most of my learning from, as well as Twitter, as always lots of great content being tweeted.
Gene: It’s so true. I think six years ago I would have laughed at you, but just as a little side note, many people might not realize that one of my reasons for tweeting is actually too, is my mechanism recording things because, ultimately, of course, you’d actually write things down. Awesome. Jonathan Fletcher, you had a thought.
Jonathan: Just to add to exactly what you guys were saying. There’s next to where I work there’s a brand new building being put up, and I find it fascinating watching that process go on. So they’re damming in the foundations and from our floor, we can see right down to the foundations and see the guys that are working. And I often think of a parallel between a building and what we’re doing. You know IT is 20-30 years old. These guys who are building buildings since the pyramids, and they know what all the things are gonna happen, and they know the tolerances of the steel.
They know how much bricks they’ll need. They know the amount of concrete they need, and they know what order it has to go up. They know they need Planning Commission 1, 2, and 3. They don’t need to get halfway up the building, commonly knock it down and start again. And I think we should strive to get there in the future. We’re actually this is a common and understood journey and there are artifacts, and processes, and cultural norms that we can call upon, and I think this is the revolution that Jon was just talking about we’re going through now.
We’re trying to work out what these things are, and I guess I have one part which becomes routine. This is the university course of the future. I’m exactly the same as Cornelia. I can remember my sophomore engineering course and they’re talking about the silo model and Waterfall and this and that. That’s how you did it. So I think we go through that process now and I’m looking forward to that becoming more formalized and recognized, I think.
Gene: Fantastic. And love this, you know as you were reflecting on this, I was thinking about this quote that I think about all the time. As someone once said, “You’re only as smart as the average of the top five people you hang out with,” right, and so that is learning only happens when you’re hanging around people that you actually learn from, right? So that’s something I think about a lot. So we are all lifelong learners, now more than ever, at least for me.
I can’t tell you how many times, it’s difficult for me to overstate how much I’ve learned. I mean it’s just I’ve learned so much, even since the Phoenix Project came out 2013. I’d love it we’d just maybe go around the panel and just share one lesson that you’d like to share with everyone that you think it has significance and importance to everybody. Cornelia, let’s start with you.
Cornelia: Yeah, so one of the phrases that has really resonated with me as of late is this notion of radical curiosity and really just being continuously reminding myself that everything that I’ve seen so far is just what I’ve seen so far. And so I find my best days are the days where I get to talk with folks, where I get to ask the questions. I like to ask questions a whole lot more than I like to talk about things because it’s there where you get those insights. Even just this conversation for the last hour has just been the best part of my day and it’s only 8:00 o’clock in the morning for me.
So it’s really about asking questions and not falling into the trap of, “This is the way we’ve always done things.” I remember somebody asking somebody about how they do their firewall rules, how they determine what those are or how they secure something. And they said, “Well, we set the firewall rules.” And I was like, “No, no, no. I asked you how you secure things.” And it was all about the firewall rules. So it’s reminding ourselves and that we all fall into those traps of we have the solution, and we forget what the question is. I think that’s my answer.
[Crosstalk]
Gene: Yeah, that’s awesome. Jonathan Fletcher.
Jonathan: This is kind of a heavy thought for 4:00 o’clock in the afternoon. I think just that I’m really not the cleverest person in the room, and to keep an open mind about what others are telling you. Because as Cornelia says, this is a changing and evolving thing. People are reshaping IT and you know you don’t have to be the smartest person to pick up on some of this stuff. This is a movement and a cult of change that is happening, being able to set out some of these ideas and the Jez Humbles…All we’re doing is sort of following behind and listening, and picking the good bits and implement ourselves. So we’ll copy other people’s ideas, I guess, but that helps me get to where I want to get to. So just recognize that you’re not the smartest in the room, and just take the lessons that others have set out for you, and learn from them and move forward.
Gene: Perfect, love it. Yeah, one of the people I admire is Martin Fowler and I think he wrote kinda somewhere about his role, and he calls himself the best dumpster diver of other people’s ideas. I thought that was actually lovely beyond words. Jon Smart.
Jon: So in terms of a learning for me, I think in terms of culture change, an org change at scale, it’s going from, “I believe it when I see it” to “I’ll see it when I believe it.” So, you know I only really see it when I believe it and you to actuate new behaviors. So what I mean by this in terms of culture change, it isn’t about just going in there and saying, “Think this way” and trying to change the thinking. People need experience. People need to experience it, and actually you need to change the behaviors to change the thinking, to change the culture. I’ll see it when I believe it. That’s a learning for me.
Cornelia: Brilliant. That is brilliant. I love it.
Gene: I love it as kinda I’ll force it into being by sheer force of will. I love it, from Jonathan Smart. Fantastic. Well, to Jon Smart, Jonathan Fletcher, and Cornelia Davis, I’m so grateful that I spent an hour with us, and I know that your time is exceedingly valuable. You’re working on incredibly important things. I can’t tell you how much it means to me that you spent an hour with us, and for this hour, I hope that everybody else got as much value and delight as I did. So thank you, again. Now you’ll see more from us about the DevOps Enterprise Summit program as it shapes up.
Again, all three people here are part of the Programming Committee, and our goal is really to make that even better than it was last year. So I look forward to, hopefully, seeing all of you, on June 5th and 6th in London at the QEII Conference Centre. And, of course, an amazing venue in the center of Westminster and the center of London. You’ll see all the updates online at events.itrevolution.com, and again, early bird tickets end the 8th of March, so be sure to register as soon as possible. So with that, thank you so much and I look forward to seeing all of you on the Programming Committee calls or rather on the panel, and stay tuned for more updates. Thank you, again.
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a 
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a 
