00:00:03

So I'm John. This is Chris, and this is about DevOps at the enterprise scale between a service provider and an actual client or company. Um, wanted to start out with, um, a little background. So this is gonna be the format. It's basically Jean Kim's, uh, order, uh, outline for, um, experience reports. And so we'll talk a little bit about the goal of the journey and then what we learned. And hopefully you'll get something out of this from specifically what we did in the journey, but also about working between clients and service providers. How many of you are working with a service provider today, IT service provider, some kind of outsourcing, just about everybody in here mostly anyway. Okay, good. Um, so let's go through a little bit of background first and then we'll jump in. So talk a little about FCA.

00:00:57

Okay, for those of you that don't know, FCA Fiat Chrysler Automobiles, um, it used to be one of the big three when we were Chrysler. Now we're number seven in the world. We operate in over 40 countries. We have a lot of employees. Um, if, if some of our recognizable products that you might be aware of, we make Jeep. That's one of the most recognizable products in the world, in the automotive world. Also, the crown jewel of the company is Maserati. So that's, that's another interesting vehicle that we make. We're really a merger of two companies as the, as the, uh, as the, the name of the company suggests. It's not our first merger. We've hit, we were dimer Chrysler before. Now we're Fiat Chrysler. The interesting thing is that Fiat is one of the, well, it is the premier automotive company in Italy. Pretty much the only one. It's been around since 1899. It has a very proud long tradition. And Chrysler was founded in 1925. It was an American company. So we, so we have two very old longstanding companies coming together into a single company.

00:02:05

And just a few words about DXC. Um, so we're the world's leading, uh, independent end-to-end IT service provider. So about 21 billion revenue, uh, 6,000 clients. And that number is probably small, but 10,000 plus, um, agile and DevOps practitioners and experts. So, um, we're increasing that number, which we'll talk about more soon. Uh, a little bit about the offering. So there's nine main offering families, 96 plus overall offerings, and you can, this goes anywhere from consulting to, um, app services to cloud services. So the whole gamut, end to end. All right. Um, so let's talk about us just briefly. So Chris,

00:02:51

So I'm Chris Gallivan. I've been working at, uh, actually at Chrysler and now Fiat Chrysler for about 20 years. So I'm, I've been 20 years in the automotive industry. Prior to having a DevOps role, I was, I was managing a, a global testing practice that we had set up across our company. And in July, I assumed the DevOps enablement responsibilities working with DXC. Um, on a personal note, I guess I have seven kids, so I have, I have a lot of kids <laugh>, so I know what it's like to deal with a lot of different personalities and challenges. Um, I'm also a former musician and, and at the conference, I know music came up a number of times. I think there's a lot of musicians in it, and I think there's a lot of similarities between music and DevOps. I think Olivier is also a musician, <laugh>, and I get to travel to Italy a lot. So that's one of the best things about my job because there's no bad trip to Italy <laugh>. So,

00:03:46

Uh, just a few words about me. So I'm a principal of, uh, DevOps transformation. So I'm working internally within DXC to help our DevOps transformations as well as with clients to help them on their journeys. Um, let's first talk about, as we go into this journey between our two companies, let's talk about the, the original goal that we, that we kind of talked through with the executives.

00:04:09

So I, I think, I'm not gonna read the words of the goal, but it's, it's the same sort of goal that most companies would have that wanna move to DevOps. They want to, they want to deliver faster, higher quality, they wanna lower their technical debt. But behind that goal, there's a lot of other things. I think there's some context that's important to understand. Um, in, in terms of the way our organization is staffed and, and, and is structured. We're in year 11 of what was supposed to be a five year transformative outsourcing agreement with DXC. And, um, at this point in time, we have approximately 1500 developers in North America. If, if you want to know how many developers we have globally, you could pretty much triple that number. So somewhere around 4,500 globally in North America, 80% of our developers are offshore. So we, we went very strongly offshore, and I was part of the team that actually did this contract 10 years ago.

00:05:02

So I remember, um, first of all, the, the contract itself was called the transformation, the kind of an ominous title, but there's been many transformations at our company over the past 20 years. That was, that was one of them. Some of the slogans, you know, like any transformation you come up with slogans, some of the slogans that we used to talk to our people about what was changing. Uh, first one I remember was we were out of the people business. We were going around telling our people that we're not in the people business anymore. You know, we're gonna outsource this work. Um, software development is a black box. So that's, that's what our service providers do best. Let's let them do it and let's just kind of get outta the way. And I think the third one was, we want our service providers to own our applications.

00:05:45

These were things that we stated to our people. And obviously, um, a lot has changed in 10 years now that software is actually ironically, uh, eating the world. I, I think that the key thing that from, from a client's perspective, that, that we've learned, or that I've learned at least, is that we need to understand software. You know, as a client, we need to understand how do you build software in, in, in a modern world. So, you know, Fiat Chrysler, two companies outsourcing, one of the things about this company is that it couldn't stand on its own. If you really look at the history, and that might sound like a bad thing, but I'm actually happy that it couldn't stand on its own. Because as a result of some of these things like outsourcing and merging with other companies, I think in some ways we're actually stronger. So today, you know, part of that is we have a partner like DXC, and we're gonna talk about how we've partnered together to try to address some of these challenges, moving to a new delivery model.

00:06:50

So the journey as we engage together in this, um, we'll kind of walk through briefly some of these six areas that we went through in this journey. So to start, we started with executive alignment, and we did this in kind of a unique way, particular to the way DXC treats DevOps. And we started this with what's called a Greenbelt DevOps dojo. So some of you may have been in the session that Joan and Olivier were a part of, uh, yesterday, where they talked a little bit about the, the, the DevOps dojo process. And there's, we adopted this from the targets original dojos when we were here at, at, uh, enterprise Summit back in 2015. We modified that and made that our own and added different flavors of the dojos. So I won't go through all these in detail. There is a presentation that you can find online that Olivier and Slavic did from last year in London's DevOps Enterprise Summit.

00:07:53

So I encourage you to go find that, um, on YouTube and, and listen to that pitch. You can hear more about our Dojo process, but the greenbelt Dojo's unique one, um, this is one where we get together with the executives, the leadership, the CIOs, the business partner, the, the, the, the executive staff. And we align on what DevOps really is. You often hear the adage that, that, um, you ask 10 people in a room what DevOps is, you know, get 11 different answers, right? So we centered on what DevOps really is for this company for FCA. And of course, a lot of people start at the tools at the top, and that's kind of their mental model of what DevOps is. But of course, we all know it's mostly all the stuff beneath it, the principles, the practices, the, the, the patterns, et cetera, and mostly the mindset and the culture.

00:08:46

So we level set on that. Had some really good discussions about that and discussions about what leadership of DevOps really means. This isn't a one and done thing. Chris and I and the account team and others are gonna be working continually with the executive team to have constant conversations about this, because it's not something that just you absorb and then you get, especially with everything that CIO does. So, um, this was one thing we, we talked through in that Dojo. The other thing we talked about is, is aligning on a set of common principles around transformation.

00:09:21

So these were the four principles that, that we agreed with the leadership on. The first one was, we had done a lot of big bang things in the past, and very few of 'em yielded the kind of business benefits we were looking for. So very clearly we were going to take a incremental approach to this. Um, we have service providers. We, we spend a certain amount of money. Nobody, nobody, uh, was foreseeing a huge amount of money coming in to, you know, redo the way we do everything here. So there was a clear message from our CIO that this was a transformation in place, not just with DXC, but with all our providers. Um, definitely it was a culture and practices led type of approach because the people were one of the more important parts of, of, of this actually the most important part of this. And we wanted to show results as soon as possible. So we had a real bias towards action.

00:10:13

And the last thing that we really emphasized in this greenbelt Dojo, this engagement discussion with the leadership team before this journey started, was an approach, a sort of a, a methodology to doing transformation. So I won't go through all the details of this here, but there are four key elements. One is the, the value stream optimization. So actually picking a set of value streams of application areas to begin with, and iterating on those using, you know, uh, value stream mapping, DevOps, kaizen, the, the dojos that we'll talk about, focusing in parallel on the cultural shift and what that means from a leadership standpoint. And we did several activities around that, and we continue to do that. Um, and then having an enablement team, having a core group that, that doesn't do DevOps for others, but make sure they enable. So this is everything from a common pipeline to, um, helping the coach to, to kind of overseeing as a, as a central group. And then lastly, a couple of levels of governance, and I'll, I'll reference that a little bit later. So from there, um, we, we, we wanted to prioritize what the core starting point was. Where do we want to begin? There's 1600 apps within FCA, approximately, where do we want to start?

00:11:28

So some of the factors that we looked at were, um, the importance of the application to the business, um, specifically applications where we know we're going to be making investments, success likelihood. So we didn't wanna pick something that was a really hard start where, where, you know, it was really difficult to prove value. So we, we, we went with people that, or with applications in areas that, that we thought we could have a likelihood of success, um, improvement, need some of these ar some of these applications. I remember there was one application where their release cycle was over a year because we have a lot of plants, and by the time they roll it out to every plant, if you add up the time to, to market, it could be a year. So those are some very, those are some apps absent need of improvement. And lastly, um, of course, if an application's only changing once a year, it didn't make sense to be a part of this, it should be something that's changing frequently. So with that, we, we came up with a set of, of applications that were spread across numerous executives.

00:12:28

Yeah. And, and then we took those application areas and we, we focused on this cross-functional learning. So we brought together the, the, the QA folks, the operations folks support, um, devs as well as the folks from the business into a week long yellow belt DevOps dojo. So if you heard Olivier and Jones pitch yesterday about the yellow dojo, we've turned that into a virtual, um, set of modules for learning. This was our version of a, of a week long session where we have games, we have, uh, simulations, we have, uh, deep discussions and, and we actually dive into all kinds of areas of DevOp. So this is just a smattering of some of those areas that, that and practices and, and patterns that we focused on. So that was a core kind of a launch pad for all these cross-functional teams to, to work on. Um, a lot of good feedback from this. And, um, and, and also there, there's, there's a lot of value in, in having people be immersed. So that was part of this dojo concept of immersion, of, of what this really means to their job. So a lot of discussions about how this applies to them. Um, then following that, we took these initial apps and we did value stream mapping. I'm curious, how many of you do value stream mapping in your organization?

00:13:50

Okay, maybe about 25%. So, um, I often say that that value stream mapping is the, the, the most underrated and underutilized lean and DevOps, um, practice. Um, it's getting a little bit more popular year after year. People are kinda understanding how valuable it is. Um, we believe it's crucial, and it's a part of our main practice at DXC. And so together we did value stream mapping for all the initial applications that we, that we worked on. And this is a whiteboarding exercise where you get the whole team together and you're mapping out end to end all the different steps of software delivery from beginning to end, um, and finding out where those bottlenecks are, where those pain points, friction points, constraints, et cetera. So that was critical. They actually took after the whiteboarding, and they decided to create a template and do this in a spreadsheet mode.

00:14:38

So they had this captured for all of them. Um, it's not a must, but it worked really well for, for FCA. Um, and then the, with those applications, we went into the Black Belt Dojo, which is the other dojos are more of a set of trainings and training sessions and discussions. The Black Belt Dojo is about less talking about DevOps and actually doing it. So we get those application teams together with the support and the cross-functional groups, and we focus on actually building out keyboards the entire week, building out actual implementations based on what was found in those value stream maps, set of improvement themes that get the teams toward, uh, measurable goals. So that, that was a key step. Um, won't go through the detailed process, but you can look at these slides after. And also, um, look at the video that I referenced before.

00:15:33

So what did we find? Um, the biggest outcomes that we found in the initial, uh, pilot had to do with what I'll call low hanging fruit. So one of the, the first things that we saw was that we spent a lot of time creating packages and deploying these packages. Actually, we were using a very antiquated way of, of doing software development, where we had kind of a, a chief developer that would take the input from various developers and then pull it onto his desktop and somehow merge them together. And, and this, this process took a very long time, and honestly, as a client, we weren't aware of this time. So this was really part of that black box that I talked about at the beginning. A black box is not such a good thing in this case. Um, so we saw some significant, uh, you know, days to minutes. It was pretty easy to achieve that with, with DevOps. We also adopted GitHub. So I know that sounds pretty obvious to you guys, but at a, at a conservative company like us to, to pick a tool like GitHub, uh, is a pretty big deal, you know, and, and basically what that allows us to do is do parallel development, which we haven't been doing,

00:16:44

Following on the Black Belt Dojo. And, and Chris mentioned some of the low hanging fruit and that continued and extended, but part of the next step is DevOps kaizen. Um, this was, this is a concept that, uh, many of you might have heard Damon Edwards talk about several years ago here at this conference and other conferences that, um, to me it's the secret sauce of DevOps transformation. It's the process of having teams own a specific business outcome or result cycle time, MTTR, whatever that specific need is, and then do the experimentation, the implementations and iterations based on what those biggest bottleneck areas are. So that, that's the follow on step that we're taking now for all these application areas.

00:17:25

And then, um, maybe you can talk a little bit about the, the, um, lemme just preface this by, when we do these value stream optimizations within, within each team, often there are items that, that, that bubble up and say, Hey, this is an org wide constraint. This is an org wide issue that we need to address across the board. Um, things that we don't want each team necessarily to solve by themselves, even though we wanna empower each team to drive their specific numbers, their, their goals, um, based on their value stream mapping, we wanna also solve some things horizontally.

00:18:00

Yep. So some examples of some of these enterprise wide things. We established what we're calling a minimum viable pipeline. We had a lot of silos that were doing this themselves. And while we don't wanna tie anybody's hands, we saw a lot of, of duplicate work that could have been done. I kind of call it the rich and the poor. There were some people that had DevOps engineers that were the rich, but then there was these other important areas that didn't have those engineers, therefore they didn't have this. So try to put something in place that anyone can, can, can, uh, take part, you know, anyone in, in the company common measures. We, we, we honestly, we tried to, what, what I'll say, uh, Chrysler eyes, the measures, but John was very, uh, he was very strong and adamant about, you know, don't get too many measures. And, and these are the industry standard measures. Um, I mentioned the GitHub, and we also use ServiceNow. And, and we, we have a lot of controls around managing the changes that go into our environments. So we've already, honestly, in a very short amount of time, we've been able to stand up something that was SOX compliant with a lot of processes and a lot of manual stuff around it, using GitHub in a period of about a month, we replaced that.

00:19:13

So looking at the follow on to this, this first set of steps in this journey, some of the, some of the next items, um, why don't you talk through a few of some of the things that we're doing next.

00:19:24

I think one of the things that, in my position in, in our company we're, we're not really interested in having pockets, pockets of, of this. We really are, are interested in doing it across the board. And I, and I don't just mean in one region, I mean globally across the board. So we're definitely trying to figure out a way to scale this across all the rest of the areas. I think one of the key elements to doing that is, is the coaching and, and the DevOps, uh, enablement that, that DXC has done. I don't think it would work in an enterprise like ours without that strong level of guidance. Um, I think the enablement teams, it's one thing to know that there's a concept of an enablement team, but it's another thing to actually physically staff the team and build those structures into your organization. Those are some of the things that we're currently working our way through. And one other thing to mention, in a very conservative company, it's very difficult to explain the value to your CFO. It's one thing to explain it to your CIO, but ultimately that means explaining it to your CFO, at least in my company. So we're still trying to figure out what's the magic there. I mean, we've hear a lot of people with a lot of examples, but that's really the honest, that's the, that's the thing that's gonna be our tipping point. Yeah,

00:20:34

That'll be a constant discussion we have with that executive team because it unfortunately still is thought of in many areas as a cost center and not as a value add center. It varies by group, by team, but we have to continually have that discussion. And you heard some of those pitches, um, this morning for instance, on how to best do that. So we're, we're, we're madly taking notes on that. So lemme lemme talk a little bit about scaling this now. So we started with our initial set between, um, between the various teams and that's been growing. But to scale this across a larger and larger group of these 1600 apps, we have a, uh, an approach that, that DXC uses and that we've customized for FCA, which is, um, based on phased rollouts, not big bang, incorporating learning and improvements at these different levels. So if you look at each one of these lines, that's a set of product groups.

00:21:34

That's a product group of many different value streams, many different applications. And so as those sprints proceed, there's parallel agile sprint work with features with the DevOps kaizen continuous improvements based on the goals and the value stream. There's feedback loops between each of those. Of course, with retrospectives, there's feedback loops that go from product group as the next product group takes this on. And then there's feedback loops between each domain or each portfolio, each ma major organization so that each learning that happens at each level then cascades to the next. Um, there's also a set of governance, um, a couple levels of governance that we're establishing. And, um, we hope to come back together in a year and talk about where we are on this overall path. But there's a lot of learnings though that we've, um, we've gotten out of this so far that we wanna share.

00:22:31

So, um, the first learning has been the alignment and alignment between the client and the service provider is, is critical. Not only even without an outsource environment, even within one company, that alignment up and down the chain is critical, but it becomes even more important between the two companies on what we're doing. And we're all aimed at the same goal. We started that with the green greenbelt dojo, but we need to continue that ongoing. So that was one key, learning that alignment is critical. Um, a second key learning, maybe you can talk to this one, Chris.

00:23:06

So there's a lot to DevOps even for somebody who's technical, you know, savvy, technically savvy. And I think you need to hear it many times before you start to really understand, you know, a big chunk of it. I think it's especially true of executives. One thing we observed is that we had these sessions, many of them were, you know, long sessions explaining this, and then we would get a question that sort of indicated that they didn't understand what we were saying. So I, I think I'm, I'm pretty sure that everybody has seen this before. The, I think the key thing is don't be afraid to repeat yourself. Don't be afraid to repeat the basics, because you should probably repeat the basics enough times to where you start to get the kind of responses from them that indicate to you that they did understand it. Don't, don't underestimate what they don't understand.

00:23:51

And, um, shifting from a tools mentality to an overall culture mentality. We all talk about it at these conferences, we all know it, but actually doing it within the leadership team and all the way up and down of what DevOps really is, is another story. Um, it's something that we're gonna keep and, uh, continue to emphasize and continue to focus on. Um, most people are starting to get that now and we'll have to continue this as we scale this across. So that's, that's a, that's a core learning that, similar to what Chris was saying, don't take that for granted. I think that that opinion is a hard one to break 'cause we've kind of been in that mode in it for decades. Um, trust between the service provider and the client is, is critical. So trust means a lot of things here, but, but the part that I think is most important is the trust that the two organizations are after the same goal.

00:24:46

The two organizations are after not just renewing the contract or cutting the cost or driving this, the, the trust is that we're both aligned to making FCA the best software development organization possible and continuously improving that and meeting some specific goals, like we talked about upfront trust that we're after the same goal. And so when you have a outsourcing engagement or arrangement, I think this is one of the things that, that, um, in especially a DevOps transformation needs to be looked at first and needs to be really continued to be nurtured. Um, leadership may underestimate the transformation, um, uh, the bottom up aspects of it. I dunno, Chris, this is something that you mentioned to me and i, I I thought that was fascinating going

00:25:31

On. So I mentioned there's a lot of transformation. There's a lot of things that have happened in the last 20 years in our company with the word transformation in the title, probably at least 10, 10 15 major things. Normally what a transformation means is somebody's gonna come and ask for a bunch of money, they're gonna put a pull together, a bunch of people from around the org, the best people, they come together on this special project and they do this thing to the org. This is not like that. This is something that honestly will happen anyhow, f from my perspective. And it was, it's happening from the bottom up. The, the danger is that they, they think that it doesn't require investment because it's happening from the bottom up. So they, there's a danger that they don't understand that the value of this could be greater than all of those other put together, honestly. So it is a transformation.

00:26:19

And another learning is, I don't know how many times I've heard the, the concept of when are we gonna be done with that DevOps change? When are we gonna be done? Where, where's the Gantt chart that shows us when are we gonna adopt DevOps for that department? What, what's the, the end date? And, and, and, and we all know of course here that DevOps is continuous improvement. So by definition you can't complete a DevOps transformation. Um, there are milestones for sure, and there are levels, but on the, on the, on the flip side or the, the corollary to that is that starting DevOps, when should we actually start with this quote transformation? So the answer of course is start now, start small, start moving forward and iterate. So I think these are things that, that many of us know. But doing this in a large organization, especially an organization with a lot of, a lot of history, a lot of success, but not, not a, not an organization that's been used to this type of quote, transformation of a continuous nature.

00:27:21

Mm-hmm, <affirmative>, this was something that was a key learning. And then, um, results ownership versus compliance. So this was a fundamental shift that, that some of the people, even in DXE and in FCA first thought of this as being quote DevOps compliant. What's this set of items that we need to do to go along with this? And that this is gonna take constant discussions, but it's really about the team owning the result. This team owns their cycle time, their MTTR, their specific goals, and they leverage whatever means needed. Yes, we have some common pipeline, some common capabilities and so forth to leverage, but, but having the team own the result is I think the most critical part of a DevOps transformation. And that's a cultural, that's a mindset, that's a leadership, that's a, there's lots of, there's lots to that that can't be found in a checklist or a game plan around DevOps.

00:28:18

That's the part that you need to focus on. So we learned that especially here, um, for sure to resist the temptation of big bang. Um, that, that's a natural tendency especially of, of, of, uh, executive management is to big bang the thing and say, okay, let's put a plan together and let's go DevOps across the board right away. Um, and then to not skip DevOps kaizen, I showed that loop around DevOps, kaizen, again, the secret sauce of, of DevOps transformation. So this was another key learning. And then lastly, to embrace this is more about FCA embracing themselves as being a high performance software delivery organization, right? And, and, and that's something that, that, as Chris alluded to before, that it's not something you outsource that ability to do software if you're working with outsource partner, still know the whole process, own the process, own the, the, the pipelines, the value streams, and then, um, the obligatory challenges or remaining things we need help from in the community.

00:29:20

Um, there's three of these that, that we listed. The first one is about mutual beneficial goals between a company and service provider. And there's a long history of decades of having contracts and agreements that don't necessarily align to win-win between the two organizations. Um, there's starting to be a movement in that direction and we're starting to engage with, with our clients within DXC to, to help try to shift that. But a lot of contracts are, are, are long, have been existing for some time. So any help on success stories on where that's been done, we'd love to hear more about that. Um, agile DevOps shift with decades of waterfall structures and mindset. So, uh, so many companies run into this where you switched agile and DevOps approaches down in the trenches, but the overall planning POR budgeting cycle kind of are thought of differently. So I think we've all run across that.

00:30:16

But any additional success stories in, in making that shift? I think sharing out, out that would be good. And then lastly, ingraining the continuous improvement mindset across the organization. Um, we do that in pockets, but how do you really do that across the board? We've had some success with that, with other clients, um, but I think this is one that we could all collaborate on as a community. And with that, um, we'll see if there's any questions. We'll be here a little bit afterwards to answer questions. So again, I'm John, this is Chris and thank you very much. Hope you, uh, enjoyed this talk. Thank you.