00:00:05

My name is Lance Knight and I work for Connect All. Uh, connect All is a value stream integration platform. Um, I've got this demonstration I put together called DevOps Winners and Losers. And what we did is we went out and we talked to our customers, and we looked at some winning strategies, some of the things that are going on in the market. So this may be a little bit high level, but give you a good, good feeling of what's going on out there with DevOps, with the consulting companies we're working with just two seconds about me. For the last 15 years, I've worked for companies that are about improving velocity in their system of delivery. I've worked for the requirements management companies, testing companies, integration companies, all on this particular topic. Now, why is this relevant? Why is DevOps relevant today? I'm sure some of you have already, uh, seen this, but let me go through some of the points, uh, that I came up with when we were talking to our customers about why DevOps is relevant to them. Well, there's these forces, uh, that are happening with all companies today around digital transformations, or both internal external forces. And these are driving change. And this change is being very, has become very important to each company.

00:01:21

The two that I'm gonna focus on today are time to market and reaction, time to vulnerabilities. These two forces seem to be driving most of the DevOps initiatives, digital transformation initiatives and so on. This is driving speed to be the new currency. So getting things fixed, getting new products and features, new supporting products and features, uh, for your products in the market to speed has become more relevant. And this is because se 87% of all executive surveyed said that it is a competitive opportunity, but at the same time, 52% of executive surveyed said they lacked a fundamental understanding of it in order to be effective. And they're thinking that their own IT systems are a blocker. So DevOps and these different things we're gonna talk about today is how we can help them achieve these different goals. This is also forcing every company, whether you make turbine blades, whether you are a manufacturer into becoming a software company so that you can serve your customers. For example, the banking industry. So I've done quite a bit of work with the banking industry over the years. They have actually had the biggest challenge as they're moving from different technologies and adopting these different technologies. And the smaller banks can't stay competitive.

00:03:00

For example, everybody remembers sometimes around 2008, 2009, it was all about the online banking experience.

00:03:09

Now there's been a shift on that. Everybody wants a mobile banking experience, and these statistics are out there that show how the whole industry is moving. Myself, I just recently changed banks. I was a small community bank. They didn't have the best online experience, so I went to another banking institution. Uh, insurance is the same way. Uh, everybody's moving to that mobile experience so that you can get better service. I don't know how many of you have gone to a bank today, but the in teller experience or in bank experience isn't the same as what it used to be. A matter of fact, what I've noticed, uh, when I go to my bank is that they're just filling out the form that I could have filled out on the website myself. So this transformation is happening. This digital transformation is happening. DevOps is a big part of that because you have to stay competitive by releasing things faster, but at the same time, you have to be overly protective against vulnerabilities. Never before have banks and industries had to change to fit that. I focused on the banks. But of course this is against all industries as well.

00:04:18

I grew up in the sixties. I'm sorry, I grew up in the eighties, um, aged myself a little there, but my first car was a sixties or seventies car. I could fix it myself. I didn't know have to know any software. I can't do that now. There was no code in my first car. Now there's thousands and millions allowed to code in every car. So the industry's changing. The way things are happening are changing. Insurance is changing the way you're interfacing with your customers. This is driving the demand for DevOps. And this is also driving the na the demand for agile and DevOps principles and digital transformation. That's why this whole industry is changing around us as we're trying to get more and more code to market with more features, but yet exposing more of ourselves to the, to the outside world in a vulnerable way. And at the same time as this has happened, has created a tooling explosion. There are more tools for softer development today than ever before. I remember when I started coding, we had a requirements management system. Maybe there were three or four in the market. Now you've got tons of task management systems out there making it hard to understand which one's deploy and when, based upon your demand and need.

00:05:43

There was one major testing solution out there 15 years ago. Now there's a plethora. And then not then get into your CICD tools, which all have an effect. So there's been a tooling explosion in the market today.

00:06:01

So what's the DevOps problem? I think we're all familiar with this. Uh, I cover this because we're gonna go into some of the difficulties that DevOps losers are having, uh, when it comes to this problem. And that is, you know, the, uh, software developers, they're developing stuff. They want to get that out to the market, they want to get that to their customers, and they wanna make sure that they're taking advantage of that competitive opportunity. But at the same time, you've got your, uh, operations teams that have to maintain that level of security, that have the audibility, the traceability. They have different goals, different objectives, and it's this over the wall kind of thing. Uh, it's also the over wall kind of thing from product management as you throw that over a wall to developers. So this whole process is kind of broken as these teams are not aligned. So again, different agendas, different objectives. We have to align those objectives to be effective, to be effective. So in order for this to work, these teams have to essentially collaborate and act as one, one group in order to effectively get new products and features into the market.

00:07:14

Now we took a, we took a survey, we talked to a lot of our different customers. And what we found out that is that 80% of all of our customers and customers we believe worldwide are entering to some DevOps initiative. That's proof of all the people in this audience here today. But we've also found that about 85% of those particular customers are not getting the success they're expecting. And that's driven for a couple reasons. 'cause they're focused on deploying tools. Now, I, we actually, my company, we offer a tool that helps you be more effective and streamline your value stream. But I'm of the opinion that you have to also look at culture at the same time or that you're not gonna get the value you're expecting out of a DevOps or a digital transformation. Now I come from old world, it, I worked in manufacturing for 20 years and we'll cover some of the points of why I have this opinion. So on the DevOps journey, what we found is most of the companies, if you see are kind of like from a quality to speed perspective. They've adopted some tools, it's kind of been ad hoc and they have to start looking maybe to get those other, where they're going to high performance

00:08:31

Product delivery teams. We also found out that large companies are gonna continue to roll out DevOps solutions and tools at scale, but we're of the opinion, or I'm of the opinion that they're gonna achieve the same results, just deploy more tools and solutions unless they address some of these other pieces, uh, of, of successful DevOps winners, which we'll go through. So DevOps losers need to start again. I put this in there 'cause of my theme, right? Uh, DevOps losers aren't really focusing on this. They're totally focusing in on tools. And that's the thing that we found out when putting this together. So what are some of the things that DevOps winners are doing? Well, here's a, a small list and we were talking to, uh, all of our different customers. We came up with this kind of small list. And we can break this down into to three fundamental areas, uh, that we noticed DevOps winners were doing. Those areas are culture, process and infrastructure. You can call these any that you want, but um, we kind of named them that way.

00:09:49

So what does DevOps culture, what do I mean when I talk about culture? Well, this is an interesting story I have here. I call this DevOps bitch day. I'll, I'll tell you the whole story around it. My wife, who is a business analyst, came home from one day. She was all upset. I said, how did your day go? Yes. I asked my wife how her day went. Uh, and she said to me that it was just a DevOps bitch day. And what did she mean by that? She meant that the DevOps team that they had at her company spent the whole day being mad because her agile team didn't groom their backlog, right? They did that wrong. Now, to me, that reminds me of the days when I was in it. I was an enforcer, making sure the process happens. You know, you have to do it this way. If you want access to those files, I need that in triplicate, so on and so forth. So it and software development have to transform into enablers, not enforcers. They need to be a enable. And she spent the whole day complaining about how the DevOps engineer complained about that the backlog didn't grm, right? That seems like a coaching moment, not an enforcement moment.

00:10:57

So what are the other things? Well, we gotta focus on changing culture as well as process. Break down the silos, create one teams. We've noticed that a lot of the DevOps winning companies we're working with, uh, actually embed the DevOps, the operations people into the software teams. Uh, and they work with those teams. Doesn't have to be full time, but they work with the team that way as you're developing and get that out the door quicker 'cause you've aligned with those different teams, I get away from that one hero story. We've noticed that that thought of single point failure as they called it when I was in it, you know, there's that one person that knows how to fix that one thing. Uh, if that goes down, they're moved away from that and they're sharing knowledge better so that you can get away from, you know, that one person when I was in it, it was his name was Emmett, I could always go to Emmett and he would fix whatever was going on with the Oracle server. Nobody else knew how to do that. So they're starting to move away from those types of concepts of, of the hero perspective. When the team is the hero,

00:12:01

They also created the single teams. They're embedding those teams. Uh, you, you may have a product manager or a business analyst on that team as well as the developers and an operational person that's assigned to work on that team. And that's, that's removing that handoff problem. And you're also able to understand your dependencies within your system of delivery as well because you're working together in a a collaborative way. They share one common goal. That common goal is getting new features to market and at the same time making sure you're reacting to vulnerabilities in a relatively fast way. Let's talk about process really quick. So what I found about process is a lot of DevOps winners are utilizing lean principles and systems thinking in order to improve their system of delivery. They're using value stream mapping, they're using system thinking flow and waste. And I'll get into some more of that as we go through. Let's talk about lean.

00:13:10

This is lean, A lot of people DevOps talk about that. This is the house of lean. There's different pieces of here. There's five principles of lean. By the way, lean is not brand new. Uh, I learned about it 20 years ago working in it, uh, when I worked on the shop floor of an aerospace manufacturer. So it's about, it's about identifying value, mapping that value stream. And there's been a lot of talk about value stream management and I'll touch on that for a minute and my perspective on it. Uh, it's about creating flow, establishing pull and seeking, seeking perfection. Over here on the other side, there's different parts of that about integration automation and so on. I'm still of the opinion that you can apply these principles, but we still need to fix culture as well.

00:13:59

I like to talk about waste for a minute. There's different types of waste and whatever you're doing lean in process, uh, mapping and value stream mapping, you wanna go from thinking about waste. You're doing that in order to approve in to, in order to improve waste. Now, when I talk a little bit about culture, some of that is overprocessing waste, right? So when I talk about when I was a younger man in IT and I managed a NOVAL network, that should tell you how old I am, you fundamentally had to have signed in triplicates, you know, approval bosses stuff in order to have access to certain folders in my Noval network. Well that's processing waste. Why do you need all that access to some simple folder? That's when you want to be an enforcer, not an enabler. Defects, of course we talk about that. Transportation waste, you know it, I think about that as actually copying files around or recreating artifacts that you're using. So if I have a system where I am, uh, managing customer feedback and then for development and I have to copy an issue from one to the other, to me that's transportation waste. And we need to be able to remove that at,

00:15:10

And that's where you come into value stream. Think system thinking and value stream management. So this example of a value stream map, pretty straightforward one, I didn't wanna get too complicated. There's another piece in Six Sigma and lean called cipo. Those are really great for inside those area process management. So you can use a CIPO to map out how things are going through your project approval process or your product implementation process. And I believe somewhat there's a confusion between process management and value stream management. We have to align those two and understand what the difference is.

00:15:50

These are just some tools that you can use. Uh, this is value stream management. This is kind of an end-to-end value stream management. There's more to this though than value value stream management. Uh, at this point, if you're talking about doing that, you also want to do value stream design, right? So I can go and map the value stream and see what, how things are flowing, but then I only use value stream design and look at waste and how I can fix my value stream and propose an end state value stream, uh, map or value stream process. Then you gotta go into value stream mapping, value stream management planning, uh, and how you can move your organization to align to these new principles that you've uncovered. DevOps winners test a lot, I've noticed that as well. Uh, they do a lot of testing in their teams, uh, continuous testing. A lot of 'em are doing test driven development. Uh, and you're testing throughout the process that enables something else though. As I'm going along, I'll talk about that. That enables continuous delivery.

00:16:56

DevOps winners use metrics. These are flow metrics. Typically lean metrics wait time. How long was an idea sat in a queue, uh, delivery time. Uh, these types of metrics are driven because what I've found is that CIOs have risen a little bit higher than if they just reported to the COO and they're sitting on the board because there's such a big difference in what they have to do today. So what I've found is that CIO needs metrics so they can report to the CEO exactly what they do. What that does is eliminate that black box, that unpredictability. I remember projects would come into my queue when I worked in manufacturing and they would sit there until we could get to them and we'd prioritize 'em as we needed. This gives visibility of how long it takes to get something to market. You know, if you have a value stream that takes two years to do a simple project or a simple product that you wanna take to market, you're gonna miss the market, but you have to figure out how you can shorten your delivery cycles. DevOps winners deploy small changes and often we've seen this a lot as well. It's easier to pull back a small change if it's not effective than it is to fundamentally

00:18:14

Pull back a big release. So they're deploying code and they're deploying that. Often they're using things like feature toggles and things like that so that any moment what they've deployed or the code that they've changed can go into production. Let's talk about infrastructure really quick. So infrastructure we're seeing is that DevOps winners are deploying code at any time. Kind of leading onto what I just said, where DevOps winners can do a code deployment on the nightly build because they've tested a lot through the process, they're implementing small changes, it makes their deployments happen relatively quickly, not months and days, but hours from that code was resubmitted, tested and put through to production. They treat infrastructure as code as well. So the infrastructure that they have, they're using um, theories around tracking their code files, their configuration files using uh, code based kind of stuff in order to make sure that uh, they've got the latest revision and so on. And everybody's working to the same revision. Whether that's in UAT or development or prod DevOps winners, we've noticed treat infrastructure as code and they even deploy a technology roadmap. So this is when I'm programming because I'm in a collaborative way. I understand where the technology is moving over time. Uh, Motorola came out with technology roadmaps years ago and we've noticed a lot that DevOps winners are using these types of roadmaps to communicate their operational strategy over time for their infrastructures.

00:20:07

That's part of treating it as code DevOps winners are integrating their systems in order to remove waste. So this is all about how I can integrate those artifacts, those systems and remove that transportation waste that I talked about earlier. Defects can easily flow from ServiceNow into Jira and all the way down your value stream allowing us to do, allowing you to do what we call value stream integration automated pipeline. So DevOps winners are automating their pipeline. So it's automating all the way through from code packets that are moving into dev automatically promoted to qa, removing that time it takes to get code from conception into production by making sure that the pipeline is automated so that your data, your test, your information is ex is the same as it's going through that process so that your continued testing feedback loops and all of that is working effectively. So what did, what did we just learn Some of the high points of what I just went through.

00:21:24

You know, you have to look at the end-to-end delivery system. It's not just about the last mile, it's about the first mile too and how that's effective. I did a whiteboard session with a company in New Jersey, the financial institution years ago, and they spent more time waiting for that new idea to get approved and budgeted than they did actually developing it. So you have to look at that as part of your system as well, that whole part of definition. Then what, what they also would do as part of that is if in your build you came up with any defects, those defects would go all the way back into that approval process, slowing their whole time to market down and in today's world speeds the new currency. So that has an overarching effect. Focus on removing waste use age old principles. So if you are a part of this, uh, DevOps strategy, what can I do to get this restarted? Well, what I would do is rally the team around the DevOps. And when I, when I talk about that, it's not just your operations teams create a, create a group of people who understand the value, trying to get that end-to-end process.

00:22:39

We try to understand what is it gonna take to change culture. 'cause to me there's a lot of different tools and solutions out there, but culture seems to be the biggest barrier in some of the older companies where, you know, it is an enablers. There's focused us so much on being enforcers and of course map the end value, uh, map the value stream, make sure you get the right sponsor and right executive sponsor for what you're trying to do and they understand the value of that. And I think some of these things will help you move from where you're just ad hoc and move you into high performance delivery and speed, where you've got excellent quality coming out, you're delivering new fa features and functions to the market, you are effectively reacting to vulnerabilities quicker. 'cause like I said earlier, never before if companies had to release more things in a digital world old and at the same time react to greater vulnerabilities and having end, end, end-to-end value stream helps you do that. And this is where you want to end up. Some of the outcomes you can expect from this, some of the things that we've seen and seen out there, you know, two x 60% more fewer flaws because you're testing throughout, you're delivering smaller batch sizes so you can course correct quicker. That's where the 186%, 168% reaction time issues comes from

00:24:13

And 30% more frequency in builds and so on. Any questions.