Tag: DOES17

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.

Cornelia: Thanks, Gene.

Gene: Thank you, Cornelia, Jon, and Jonathan. Bye-bye.
Want to see what Jonathan Fletcher and Jonathan Smart presented on last year? Check out all of last year’s DOES16 London videos here: https://www.youtube.com/watch?v=1lU1v71ogZE&list=PLvk9Yh_MWYuyCbvBaToq9VlvRrh8otYBu

— Alan Shimel