Steve Boone

Thank you folks so much, first of all, for coming. I know we're probably the last talk between you and a decent meal. So thank you for sticking it out. I'm sure you haven't heard anything about value stream management this week, so you're probably fresh and ready to go and talk a little bit more about it.

How many of you guys know UrbanCode as a product brand? I want a couple of minutes right up front. I know we've had some confusion at the booths, people going, "UrbanCode? I thought you guys were with IBM." We absolutely are with IBM. We were an independent company. We got acquired in 2013 by IBM, and we're in an IP partnership with HCL. So if you're going around to the IBM booth and you're seeing some UrbanCode branding, and you're coming over to the HCL booth and you're seeing UrbanCode branding, it's because our products are available through both channels. We've been very fortunate to get the investment and backing of two really big companies to help go and really tackle what we're looking at as the next decade of DevOps challenges.

Clearly, you guys are here. You know all the benefits of DevOps. I'm not going to expound a bunch of information and tell you why it's important. I think some of the things to call out is that earlier on, we focused a lot around automation and helping teams construct CI/CD pipelines, help them automate testing, help them try to give a little bit of governance around their process, make it repeatable, make it predictable. And all of that effort that we put into that brought us a lot of really good value. We were able to start to reduce failures and have better outcomes. We were able to move more quickly. We were able to eliminate waste. And in general, being a part of app dev teams was a little bit more enjoyable than it had been in years past. We could talk to some certainty about the outcomes of our development practices. We could plan with more certainty. We could communicate back to the business how we were trying to do and the things that they were hoping to get out of our code.

But as we talk around and we look to other customers, we use this example of SAFe as one example. There's still a long way for us to go within the industry. We look around some of the different areas of practice here: team and technical agility, DevOps and release on demand. When the folks at SAFe did this, they polled a lot of folks and said, "Well, hey, where do you guys-- how do you define where you're currently at? Are you walking? Are you running? Are you flying?" And most folks said, "You know what? When it comes to agile, we feel pretty comfortable. We're walking." And I think for some of us who live and breathe this every day, we feel like it's much more advanced than that. All of the teams, especially when working with folks that are using newer technologies, they seem like they're just sprinting at the speed of light. But the reality is the rest of the business isn't quite there yet.

And as we go out and start talking to customers and understanding, "Hey, now that you have loads and loads of automation, now that you're trying to do automated testing, now that you're looking at trying to manage your governance, what are some of the bigger challenges that you're facing today?" this is the information that we've gotten back that I want to share with you guys. We'll see if they start to relate a little bit.

First thing we hear is, one, we have trouble connecting IT value to business value. What are our development teams working on, and how do we know that the things that they're working on are exactly what's important, or most important, to the business at this time? Think about your development teams. How often do they get distracted or asked to pull in many different directions? Whether it would be, "Hey, can you put out this fire and help this customer over here?" or, "Hey, we need you to jump in on support and spend some cycles there." There's a whole lot of balancing planned work versus unplanned work, but also making sure that that work is aligned to the business.

Also, we talk about organizational culture. When we talked about DevOps, especially at this conference over the years, we've talked about people, process, tools, and especially culture, with culture essentially being at the heart of all of DevOps. So as we start going wider across the organization, how do we influence that culture? What can we do to get people to say, "Hey, I want you to change the way you think about delivering work. I want you to change the way that you're doing your job today for the better of the business." We want to do that so that we can get them on board, but then start to identify things like best practices across those teams so that we can communicate, go, and educate others and say, "Look, I know how you're operating today is what you're used to doing. Here's how other teams are doing it. Here's the results they're getting," and try to steer them towards what we'd hope are better practices.

Then across the flow, we say, "Hey, how do we optimize?" We just don't want to optimize just development. We want to start optimizing the rest of the business. How do we get from "I have an idea" to "I get something into the customer's hand"? What are all of the different steps along the way that that business value or that idea travels? How can we track it? How can we understand where it sits and it waits? How can we speed it up as fast as possible, but still keep the rails on the train as we talk about things like quality control and we talk about security and governance?

How many of you here have more than one automation solution at this point in time? Probably a handful. And it's just growing more diverse as the years come. As we start looking at different technology stacks, everything from mainframes to microservices, you probably have a ton of different tools. Some of them are doing middleware automation, so maybe you have things like Chef and Puppet and Ansible. You've got Jenkins, you've got Xebia, you've got UrbanCode. And as we start looking at all of these different technology stacks and tools that we have, we start asking ourselves, "Well, how do I tie it all together? What's one thing I can do where I can start saying, not only do I want to have visibility across these tools, I also want to have some orchestration and some governance across them as well?"

Governance is kind of the keyword that we keep hearing. As we're reaching out to customers and saying, "Look, we have all this. We're investing all of this money in DevOps. How do I bring it to a higher level? How do I roll it up to a C-level executive and say, 'Look, this is the business value. This is the ROI that we're getting'? And what can DevOps do for us today to help us attack some of the bigger challenges?" How do we start automating things like governance? Can we automate things like governance? Can we put visibility and set expectations around some of these more challenging tasks? And then the last one is increasing the frequency of production releases. If we can shift left a lot of the things that we're talking about, we should theoretically be able to move faster.

I've got Chris Nowak with me up here. Chris, you've been solving IT challenges now for 17 years at a lot of large companies. Do you want to talk a little bit about what you've been seeing in some of the enterprises and how they're approaching some of these challenges?

Chris Nowak

Yeah, sure. Just on point number seven, value's never really realized, not just until it's operating in production, but until the users are happy as well.

One thing: we did neglect the safety briefing. Steve and I walk around a lot. If we're getting near the edge, I would ask you to do one of two things: either wave us off or sit back and enjoy the show. One of those two things.

I'm fairly new to HCL, but I grew up in a regulated industry. I worked in Wells Fargo, Bank of America, consulted to other banks for quite a while, so had to deal with it all the time. Compliance, governance, right? Is that anybody's favorite thing to do? Yeah. Mine either, but we had to deal with it.

I don't know where I found this, but it struck with me. If we have to deal with this stuff or if we're going to be near it, let's address it. The way I think about it too is, in times past, not too long ago, we would say, well, if I'm in operations, we're aiming for zero failures, zero downtime. Is that realistic? Does anybody ever achieve zero downtime? Six nines, right? So what do we do now in DevOps? What do we talk about now? MTTR. Why? Because we realize it's just silly to say we're not going to fail. I think governance is the same way, frankly. We have to think about it. We're going to have to deal with it. And there might be some of you out there that say, "Yeah, I don't have governance where I am." Okay. We're going to go down that path in just a second.

What does your business care about? I have three things that I like to put up there. What do they care about? Money, so revenue or value if you're a nonprofit, potentially. What else? Time. Cost. Outcomes of the product. Customer experience. Reputation and risk. The way I look at it is revenue or value, cost, and risk. Create it, protect it, or your reputation goodwill. On a balance sheet, there's this line called goodwill. It means all that stuff we like that we can't actually put a number on: brand names, whatever. Cost, you're either reducing it or avoiding it. A penny saved is a penny earned. And your risk, there's always risk. Anticipate it, control it, mitigate it. What we want to be able to do, though, is understand that risk is always there, and if we control risk, we can actually really influence revenue and cost. So I'm just going to go down that path for a while.

Risk-based decisioning. If we're going to do something, let's be intentional about it. Managing that will allow you to maximize the other two. If you're in IT, you're probably realizing now at this stage, at this conference in DevOps, the better you can speak to the business in their language, the more they like you. Friends are good.

Here's a bunch of different risks. I only want to talk about two. The fact of the matter is there's a bunch of them. They're all over the place. We have to manage this stuff. Alignment risk, though, I think is really interesting because what it means is, in IT, we like to do things. We like to create. But are you creating the right things at the right time? Very often, we get stuck doing something that may not actually be aligned to the business objectives. Are you aligned to the epics, to the goals, to the vision? That's important, because if you're out of alignment, you're doing really neat things, but it's not what everybody else is doing or what the business wants.

The only other thing that's kind of interesting is the opportunity cost risk. If we have great developers and we automate the build, you have all these builds waiting, but testing isn't automated, and the builds are just stacking up and stacking up and stacking up. Is any value being delivered? It isn't. It's sitting there. It's perishable. I believe that software on the shelf is perishable, which means that there's an opportunity cost that the business paid you to do in three months, but the software's not out the door, and they might lose that opportunity in the marketplace. I could come up with 100 examples, but let's say you're competing with another bank for a credit card campaign, and they make it to market first because we couldn't get through testing. Opportunity cost, opportunity lost.

Trick question. Who here is subject to governance? Is anybody not subject to governance? I think governance is actually a big word. At some level, we are subject to some kind of governance, even if it's social norms as we collaborate. Classic stuff, GDPR, hot buzzword of the year. But if you're at a smaller company or you're like, "Well, I'm not a regulated industry or publicly traded," well, you still have these things. Your CEO or your CFO is going to say, "No, you can't go on that trip. I'm not authorizing DevOps Enterprise Summit." It's governance. Your peers. Agile practices. Isn't that a form of self-imposed governance? Why? Because you want to be disciplined and predictable in what you're doing. Even if you're running your own LLC or whatever, you still have governance somewhere. You're dealing with it somewhere.

So let's not pretend that we're not going to fail, zero failure. Let's talk about MTTR in this perspective as well. In your daily routines, reduce the risk, control the cost. Take that dragon into your calculations. You're living near it. You have to deal with it, so do it. When you do these things, if you're intentional and transparent, you can then create risk-based decisioning. You're like, "Yes, we know we're taking this risk and this is why." We're in Vegas. I'm holding on 17. Understand why you're doing it. There are some examples: governance in your IT shop, quality testing, security, agile in process, paired programming. That's kind of a form of paired governance. You're holding each other accountable. And obviously ITIL and ITSM type things.

Own it or they'll own you. You're always dealing with governance, so why not do it well? The value prop is by doing that, you can address these other things. Especially with automation, you can make governance very non-invasive. We would do certain things automating in the bank where there was this governance happening, and it never got in the way of development or operations. It's easy to do. Just embrace it. I would always actually look for the auditor. If I was asked to stand on a platform service team or something, one of the first groups I would find would be our internal risk and audit and say, "Come here. I want to show you what we're doing. Is this okay? Do you have any ideas?" Now they're your friends. I would rather have them with me than without me.

They were really happy to do it because it also helped them. It decreased their time of audit, their consistency. It was just good all the way around. Out of all the things I could tell to developers to use my services, I would say, "Well, wouldn't you like to be home Friday night, coach your son's lacrosse game, or go have dinner with your spouse or whatever?" The one thing I said, and I said it by accident, that always got them to say, "Yeah, I want to do that," is, "And by the way, you don't have to deal with audit anymore." They were like, "What? What did I say? Audit?" That was it. I could have been saying that a year ago. We'll help you get there doing it the right way, and audit's on board with it.

So own the tech. Automate the governance. It can be done. Make it non-invasive. And then optimize the value stream by building these things into your value stream. Hopefully we don't have such a bad view of governance and those types of things because we are going to have to deal with it, and Steve can kind of talk through this with you.

Steve Boone

You said some interesting things there. You said transparency about that governance. I think that when we start looking about and we start talking about value stream, value stream lends itself a unique opportunity to assist with governance problems, but then also provide that transparency and that visibility up to leadership to know exactly what's happening across their development teams.

When we're talking about end-to-end value stream, we've got to understand that we really need to go wide. We always say DevOps is a team sport. We need everybody to participate. It's not an individual sport. How do we get some of these other parts of the business folded into what we're doing? A lot of it is, we have to understand how the different relationships between these teams work. Classic examples could just be look within a small development team. When we're here at this conference, we're talking about value streams in a number of different ways. At UrbanCode, we think about it closest to what we know and do and love, which is streamlining automation. If I think about a development team and how they talk with our design organization, or how they talk with our documentation team to get products and features actually delivered into the tool, those things all have different value streams. The way my design team takes work and iterates through that is different than the way the documentation team takes its work and iterates through that. There is a cost of, "Hey, can you help me with this? Can you do this part of this job? How long does that take?" When we start to summarize all of those different moving parts and pieces, we can start to calculate how long things actually take. We can get more transparent about how we make our estimations to the business. We can deliver more accurately and more predictably, which hopefully is much more of a successful experience for our customers.

What does this look like? I stole this slide from Jonathan Smart. If you haven't checked out any of his blogs, I highly encourage you to do so. They're very good. A lot of times when we're looking in the organization, it feels like, yeah, we're so agile. We're doing all of the things great, but the rest of the organization isn't. And so it's our jobs as stewards of DevOps best practices to be able to help the business adjust. The way that we're going to be able to do that and the way they're going to be able to influence other people is by creating healthy conversations. If we want to have healthy conversations and encourage people to change, does anybody know what we need to have that conversation? We're going to need data. We're going to need some kind of visibility into why am I asking you to change? What is in the benefit for you? What are other people doing in the organization differently, and why is it valuable?

Chris Nowak

I think that's actually a really important point because very often, what I always found was we never really had a lot of data, or the groups I talked to, they didn't collect data. I always did. As an engineer, it's just something I always did. And I found out that that was actually a good way to have an objective conversation because everybody has a passion around things, and to say, "Well, let's approach this together and just look at the data. What does the data say?"

Steve Boone

Yeah. And I think when we start looking at the data, what we see is there's a lot of waiting. There's a lot of hurry up and wait in our business. If we can add visibility around that, we can get more of an idea of where it is that we're waiting.

Just within our own world, I'll give you an example on our own development team. We go through several different processes of code review. We call it plus-one and plus-two, and only senior developers can do plus-two code approvals. When we've got to manage our work in progress, eventually we have too many things, work gets backed up. We start looking at the data, and it tells us that a lot of things wait in code review, sometimes a day, two days, before they actually get finalized, approved, and then merged. How can we go about changing that? There's a couple of options. We can decrease the amount of work we have in progress. We can work and take some of the younger developers and educate them and try to get them on a path to be senior developers so that they have the ability to make that plus-two. But ultimately, what's important is not how we solve the problem, but that we're having a healthy conversation about where the issue is, and that we can have a meaningful way of trying to figure out how we solve it.

Why is it that visibility is essential? Well, it's really hard to get visibility. All of the information we want is essentially scattered amongst a number of different tools. If you look at just some common examples, how many here of you guys are using Kanban boards? Are you diligent in updating those Kanban boards? Is it a morning thing? Are you coming in all the time and saying, "Yep, I just finished this. I'm going to run back over to that board and move that ticket"? If you are, great. What we experience is that that's usually a morning thing, where people come in, they look at the board and go, "Oh, wait. Hey, I did that thing," and they move it. So it's not by any means a real-time update.

When we talk to companies about, "Hey, how often do you look at and take a look at your whole end-to-end process?" they say, "Oh, six months to a year. We try to do it twice a year just to see in general where we can improve our processes." Well, twice a year is by no means agile. It's by no means anything that we would associate with DevOps. We want to start doing these things more frequently. We want real-time updates in where our work's actually sitting and why it's sitting.

Other tools we look at are CI/CD pipelines. I know you guys probably have 30 different pipeline tools at this point. But what are those pipelines telling you? They give you a little bit of information into what's deployed where, maybe a little bit of an audit trail, but they don't talk about waste. It'll tell you, "Hey, it took me three minutes to deploy that thing into QA." How long does it sit in QA? What are we doing with it in QA? What tests are we running? What are those tests being run against? All of a sudden, those are the questions that start to come up.

If you've attended a lot of these talks this week, which I hope you have, you've seen that people have built really elaborate dashboards. They're coming in and they're trying to extract this data themselves so they can see, well, how many deployments are we doing? Are they successful or are they failing? What kind of security scans are we running? They're putting this data together as a dashboard, but the real power is in the relationship of those data. It's one thing to look at, have my deployments been successful? It's another thing to look at, what are the test results that map to those deployments? It's one thing to look at, have we actually started a particular development process? It's another thing to look at the actual Git commit that's tied to that development process or that Jira work item, so that we can track it feature by feature as it moves through the pipeline.

From an UrbanCode perspective, these are some of the things that we're standing up and trying to approach. We're looking at the value stream as a way to solve a lot of these challenges that we've been talking about today, and we're looking at it from a couple of different ways. One, we want to be able to connect and visualize all of your pipelines. If you're re-architecting applications into many different microservices, that could be a single Jenkins job per microservice. How many of you are building microservices with zero dependencies in them? Amazing. I would've thought maybe one person who's like, "Yeah, we're doing that." But the reality is there's dependencies between these things, so you're going to need to orchestrate across those different pipelines, and it's not just going to be one tool. Already, when we go into enterprises, they're telling us, "Well, yes, of course we're using CloudBees. We have a ton of investment into the CloudBees Jenkins. We're also using Chef and Puppet and Ansible." So how can we then start to orchestrate across all of these different pipelines, aggregate that data, and at the very least, represent what's where?

The second thing we start to think about is we want to actually use quality gates. We don't want compliance theater. What's compliance theater? Compliance theater is where we've been with DevOps for a while. It's, "Hey, did somebody approve this?" And you can build these wildly complex approval processes to go bug people at the start and things get scheduled. But let's actually just go look at the source of truth. For a lot of people, that's ServiceNow. For other people, it could be any number of tools. What it could be, and probably what it should be, is your test data. How do we actually get smart about using the data that we're capturing as smart gates for yes or no decisions? Should I go to production? Well, I don't know. What's the data say? Are the test results of quality compared to what they have been? If so, hopefully our confidence is higher there.

Chris Nowak

I think the change advisory board is a great example in a large company about compliance theater. Many things with dependencies that nobody knows exactly how they're related, except maybe one person knows how they're related, and a bunch of other folks opining on it. The intentions are good. It probably grew up out of a reason because production blew up once. So the intentions are there, but we have to examine that, continuously improve the processes as well. I'm not saying that the CAB should go away. I don't think it should. But I do think in this kind of a world, it takes on a very much more meaningful form. You have to think about it that way: how can we use CAB the right way? Let's automate some things in it so we know these things are working. Let's check dependencies.

Steve Boone

Very good. How many of you have started quality initiatives only to watch them peter out after a while? Always goes on and happens. And part of that is, again, we lose visibility into what's happening. We start writing certain types of tests, but then as we add new code, we don't necessarily keep up with it. So do we have some way of saying, look, how do we look across all of our teams, be able to look at a product team and say, "Hey, here's all of the different types of tests that they ran: static analysis, code coverage, whatever it might be"? We want to pull those quality results in. We want to be able to easily identify them, not just for the individual teams, but for the overall company itself, who can look down and say, "Hey, this team's results are either poor or they're not publishing them." It's not necessarily to go and point a finger. It's so that we can identify areas within the business who need help. Maybe that's in the form of training, maybe that's in the form of tooling, maybe it's whatever it might be. We want to be able to surface that and actually go give them the help that they need.

Other piece of that is when we have these individual ideas or these work items or business value that we're pushing towards our customers, there's a chain of custody. They're going through many different tools. They build an audit trail. They start to collect data of themselves and with themselves. Having a single place where we can go to and understand this ticket, where has it been, what tests have been run on it, what are the results, who ran them, how long did it stay in a particular area, becomes increasingly more important, especially when we start talking about audit.

How many folks here have been through a banking industry, some regulated industry, been through an audit with the auditors? You know this is important. The first thing they do is they bring you like 50 change controls, and they're like, "Prove to me the developer didn't release this code on this CR." And you're like, "Okay, here we go. Screen cap city is coming." Then you have to walk them through and go, "Now look, here's the group and the developer, and then look at this screenshot." We want to avoid that, and that chain of custody is really what's important there.

Last, I'm sure you guys have heard plenty about key metrics. We've already talked about them quite a bit on stage just here, but we want to surface that up for all teams. Here's where I think a lot of companies struggle today. If we can capture your lead time and your cycle time and your throughput, we can display that. As a company, you can go, "Okay, that's good," or "That's bad. What do I do about it?" That's where we're trying to not only surface these things but then have meaningful conversations around, "Okay, well, let's talk about your lead time. Why is it so much longer than everybody else's? What is the experience that this team is having?" It allows us to have a little bit more empathy across teams to understand the struggles that they deal with day in and day out, to share those empathies, and ultimately improve culture overall.

When we start thinking about the different metrics, how we've been thinking about them has evolved quite a bit. We used to just kind of look at work in progress and velocity. Now, clearly you guys are much more focused on, and as we all are as an industry, lead time, cycle time, throughput. But what I want to get up here is these metrics tell a story. Two different examples of some test teams that we were working with: both of them have really good lead times, both of them are improving on throughput. But when we start looking at the two different kind of tale of two stories, Team A, while they're doing more production deployments, is actually failing more frequently the faster that they go, and they're introducing more defects. Team B has a very similar lead time. They're doing similar amounts of deployments. They're introducing fewer defects, and their throughput resembles something that we would more hope to see, which is more and more features being added without introducing more and more defects.

Looking at this data is one thing. Just being able to have the information of how many deployments we're doing doesn't tell me a whole lot. But if I can look at how many deployments I'm doing in terms of the types of stories that we're delivering, the time that it takes, all of a sudden now I can get a much more robust picture of how successful teams are being. And if I'm looking out and trying to find areas to help those teams, I've got a wider approach to solving those problems.

All right, so if you haven't stopped over by our booth, please come and do it. This is the UrbanCode Velocity product. We'd love to give you guys a deep dive demo. This is exactly what we're trying to do: build these relationships across these tools so you can define out your entire value stream. You can start to come in and define out the various different stages in JSON form. We'll bring this data into the tool. We'll start building that chain of records. Then as we drill down through this, you can easily drill down into any one of these dots, understand the different metrics that have come out of it: how long have things been sitting in certain areas?

One of the other cool things that we can then drive down in there is understanding, from an auditability and a traceability, who's worked on this, who's touched it. So if you're running monitoring tools and all of a sudden we have an alert, and we know exactly what business value is impacted by that, we can go directly to the key people. We know not only the folks who touched it, we know the people who tested it. We can trace that all the way back to the source code. And that, at the time, if you're looking to improve things like MTTRs, all of the key metrics that you want to have when trying to facilitate that.

I know, Chris, we were talking earlier about when we want to roll these things up to a C-level executive. Tell me some of the things that you guys were always looking for and focusing on when having these conversations.

Chris Nowak

I guess it goes back to these three points. People, based on your role and what you're doing, you do have interests at different levels. If you're a development team or an ops team, of course, you're looking at your piece of that pipeline. If you're an operational manager that might span groups, sometimes you have embedded testing, or I've seen production support embedded with development. You probably care about two different flows that are merging, and that's a higher level of importance. At one level, at a developer's level, maybe you're looking at just commits and things like that. The next level, you're actually worrying about the flow and the handoff and, frankly, the friction and the cost of delay as it moves from one state to another. I've seen estimates that the handoff is upwards of 70% or 80% or 90%. It's just sitting there in a wait state, like a factor of 10 off. Those are the things you have to look for as a cost of delay.

At the top of the house, all of those things roll up. Your CIO: interesting that I have 14 Jira issues? They probably don't care about that. They're like, "All right, what's the dollar cost on those things?" Am I talking to your upper-level execs or transformation folks? Is it revenue, cost, or risk? Am I decreasing and increasing appropriately? That's always where the conversation's going to go. You can't get there to start. You have to actually start at the base level and aggregate the data up and look at the relationships. But that's always where the conversation will go. If you want funding for a project, business case, how do you do that? Data. I'm going to save you this much money, make you this much money, or you can avoid talking to the OCC.

Steve Boone

Awesome. Well, I thank you guys. I know it's been a long week. I appreciate you coming. I know you're ready to go cruise over to lunch. Thank you for sitting here and learning a little bit about value stream. If you're interested in getting started with value stream, check out our e-book. You can just hold your phone up, take a picture of that. It'll take you straight to the location. You can download it. It's a really good read on how can you go back after this conference and sit with your teams and say, "Hey, let's talk about our own value stream." We don't need tools. We need conversations. We need to be open and honest about how we work, how we communicate, and from there, plot out your own value stream.

If you have any questions, come see us over at the booth. We're giving away all sorts of good stuff. Get a chance to win $100. That doesn't suck. Just don't blow it at the blackjack table. All right, guys. Thank you again. Appreciate it.

Chris Nowak

Thank you.