00:00:12

Hi, my name is John Edgar. This talk is called attacking the fuzzy front end of value streams. So I'll give a little more detail on what I mean by the fuzzy front end and talk a little bit about value streams, essentially. This is a, a DevOps agile transformation story and experience report about how we did this internally within the XC technology. So first a little background on me. I am a DXC distinguished technologist and a dev ops agile transformation principle. So that means I work with large enterprise companies and helping them on their DevOps, agile journeys toward business results. Um, I also do this internally with our group. We do transformations, um, and, and help with the DevOps agile journeys across our own organizations inside of DXC. And that's what this experience report is about. I've been in the industry for over 25 years, uh, as a, uh, architect and a, uh, technology executive in it and in that R and D over the years.

00:01:18

So who is DXC? Where do I work? So DXC technology is the world's leading independent, and then it services and solutions company. Um, some of the, some of the details of what we do everything from it, outsourcing cloud migrations, cloud capabilities, application services, analytics, engineering advisory. So a few of the numbers shown on the slide, um, over a 20 billion in revenue, over 6,000 enterprise customers, um, over 23,000 agile DevOps practitioners. And, um, one thing to note is we do over 14,000 cloud application migrations per year. We're also a, of the industry dev ops and agile leader recently. So that's who, uh, VFC is a little bit about where I fit in within DXC. So, uh, part of our DevOps agile enablement offering, uh, we have a group that focuses on, on building out this enablement and helping customers and internal groups with their DevOps agile journeys.

00:02:27

And so you all can think of enablement or some people think of enablement as tools and, and helping with methods and tools for our dollar DevOps. We know that that's only the 20% and it goes a lot further than that. So this sort of depicts, what's what we, what we do and how we help. And this fits into this, uh, transformation journey that I'm talking about in this experience report. So all these elements here of this enablement, um, are, are, uh, targeted for our customers with continuous feedback loops, as well as within DXC. So kind of going around the circle here from, from the top, counter-clockwise what makes this offering up? What are some of the things that we, um, that we do to help with these transformations first there's these dojo's? So we have, um, world-class dojo's that we started, we designed back in 2015, you may have heard other presentations by DXE, uh, and experiences with DXC on our dojo.

00:03:25

So these are immersive hands-on coaching led sessions to help accelerate the DevOps and agile journeys. Um, we've also branched out and made other types of dojo's such as executive level Greenbelt, um, uh, DevOps and agile dojo's, um, as well as we've created some self-paced online, um, um, uh, persona based training modules, uh, and we've made those open source recently. So you can find those, uh, those yellow belt dojo's online in, in, and get home. Um, value stream mapping has become a very poor part of the transformation, uh, repertoire, if you will, we will, we will talk more about that. I'll go into that. Uh, as part of this, uh, experience report, we build out patterns. This is key. We build up patterns across our offering across DXE document those in our GitHub, repos, and continuously improve those patterns. And these patterns are everything from enterprise transformation, DevOps transformation patterns, to, uh, team patterns, to technical patterns on, on adopting DevOps and agile for results.

00:04:33

Consulting is a key part of this. So since, since tools are only a small part of this, a big part of transformation is management of change. It's leadership. It's the culture, it's how teams work. So consulting is, is a key part of, um, of the journey, a transformation framework, which includes kind of governance and how to think about transformation in an agile fashion. I'll talk about that, uh, momentarily. Um, we do office hours inside of DXC as part of these transformations to help teams share and learn from each other. In fact, this gene Kim model of, uh, of experience reports, we do similar, very similar format, and we do that internally across our company. Uh, every two weeks, we're doing that for about three years and last but not least coaches kind of it's the, uh, the heart of what transformation is about having enablement teams with key, uh, skilled coaches and building out more coaches across an organization is key.

00:05:33

So with that, in this experience report for Jean Kim's format, uh, talked about the organization, talked about where I fit in. So now let's get into the business problem that we want to solve, um, kind of where we started and why, what we did the outcomes and then kind of where we go from here. All right. So first the business problem, the business problem that we wanted to solve, this is within a large organization inside of DXC awards it organization. Um, the goal was to get to faster lead times. So from the business request, business need all the way out to, um, valuable features in production. How can we increase that? How can we, um, increase the speed of that and shorten that time while increasing quality? And the third item was not just to do this with a couple of application areas or a couple of ice streams, but to scale out that transformation across the large organization. So using a, an initial lighthouse application or an area that we have, some, the team felt like they had control over that they can get a win and then extend that and expand that and leverage that for a broader transformation. So the team started with this, um, uh, initial application, which was around managing master data across all it systems.

00:06:57

So how this was approached, uh, stemmed first and foremost from a set of patterns. Um, and, and in a way it's a set of patterns that are antidotes for the common anti-patterns that we see in the industry. And I wrote a white paper on this a year or so ago. The link is there, but just a quick summary of that, which, which kind of leads to the approaches that our teams are taking, is that an anti-pattern typically, uh, you see is modernization for modernization sake, or trying to get to some maturity level, um, doing DevOps or agile for the sake of dev ops and agile. Rather, the approach that is, is more effective of course, is to focus on the business outcomes, treat the dev ops and agile as a, as a means to the end, as a means to getting measurable, specific outcomes, rather than looking at this as let's reach this maturity level, or this reach, this, this, um, this, this, this checklist of dev ops items.

00:08:01

The second big anti-pattern is big bang, uh, trying to do a transformation and have a Gantt chart and lay it all out and say, we're going to go from here to here. And this is a one big transformation, a better approach of course, is to treat agile and DevOps transformations in an agile fashion. In other words, short, um, small, uh, efforts with feedback loops, assess, adjust, get value as you go, and, um, and, and, and reach the outcome goals through iterations rather than trying to do a big bang trend. The third, uh, transformation or the third anti-pattern is around technology and methodology focus. In other words, focusing on only the technology or the agile, um, ceremonies and methods, rather than looking holistically and focusing on how teams work, the culture, um, the leadership, um, and all the other aspects of change. And the last anti-pattern we often see is, and this is the one that plays mostly into this change, uh, that we, that we worked on is this thinking of, of DevOps and agile is a one size fits all venture.

00:09:13

In other words, taking a set of steps, things that you want everyone to do across the organization, and have everyone do those as if they're going to solve every team's main bottlenecks. Rather the antidote for that is to look at the value streams and figure out what the specific bottlenecks are within each value stream, and then attack those things, right? So if a certain constraint or a bottleneck or a pain point in one group might be one thing, it might be different, um, in, in other groups. And so rather than thinking of it as a one size fits all, focusing on the bottlenecks that make most sense for the value stream, this is where value stream mapping really comes to play. So a quick, um, overview on what that is for those aren't familiar with value streams, advisory mapping, the value stream is, um, basically a sequence or a stream of activities from end to end that start from some trigger point and go to some value at the end, right?

00:10:13

All those steps, those hand-offs, those, those, um, processes and, and, um, and systems that it takes to go from beginning to end on the bottom left is a textbook example of a, of a, of a value stream map of current state. The power of value stream mapping is in seeing the end to end and seeing where the big bottlenecks are for that value stream and really getting the cross-functional team together to collaborate and to all see the same view rather than one person coming in and seeing what they need to do in their silo. What another function like ops needs to see to, to optimize their silo we look into and how do we make sure we get the right value at the right speed through flowing through the value stream together, as one, as one thing, rather than each having their own little parts, very powerful.

00:11:04

And I would add that it's a mistake. A lot of teams make and doing vice-chair mapping is they think of through mapping in the traditional sort of classic value stream mapping, lean perspective. Uh, it definitely leverages lean, but we like to look at it more from the perspective of, um, software being different and looking at it, um, from a, from a, um, maximizing the flow of software, which might be different from the old manufacturing lean way of looking at things. Um, there's several idiosyncrasies around software, things that you can do with fast feedback loops with, with flow with, with shifting left, that might not be in traditional lean. So by looking at the patterns within software delivery and applying that strategically end to end is sort of the, the way we like to look at value stream mapping. Okay. So the way we approached this, this, this business challenge, this goal is by running through a, starting with the value stream mapping process.

00:12:05

So we use a five step process, uh, the first being the charter, the most important step kind of going through, what is the scope? What are the goals? Um, what, what's the use case? What's the first trigger? What's the final step of this. And from that deciding who cross-functionally end-to-end should be a part of that, then steps two, three, and four are the, or the workshop. So step two is the current state value stream map, um, documenting what is, and getting everyone to look objectively at how things actually work. Uh, step three is the future state value stream map. From there, step four, we take, uh, what those countermeasures, what those hypotheses would be of what we could do, our improvements we could make to go from current to future. And then we prioritize that list and I'll walk through what we did in this specific case.

00:12:58

Uh, and lastly, step five, the most important step, which you could throw away all the other steps. If you don't do that, that's this Kaizen process of continuous improvement executing on those countermeasures, um, implementing something against the goal, assessing, adjusting, and then targeting the next thing and going through that loop, that's the secret sauce of dev ops and agile transformation it's doing that, that stepfather. And then lastly, you'll see the pyramid there in the middle. You might recognize this from other DXE, um, presentations. This is kind of core to our whole approach of, of, uh, DevOps and agile. And let me just walk through that real quickly. So, uh, this pyramid represents kind of all the different aspects of dev ops and agile. Often people look at the tools, which is the, the top part of this that's the most important tools are of course, very important, but probably the least important of all the layers of this pyramid for DevOps central transformation.

00:13:56

So more important than those practices and patterns that underlie it more important than that, or abiding by the principles and then under that are the basic mindset and culture. So if you look at the top of this pyramid, these are the easier things to do. Um, they're more visible. Uh, also they have the least impact generally, as you go down to the bottom, these are the things that are the least winnable. Uh, they're, they're really hard to do. These are the harder things to change, but really important have the biggest impact. So, um, looking at across all of these as important, not just one or two layers, um, and paying attention, especially to the bottom layers and, and you'll recognize some of the mindset and culture items, and you'll recognize the three ways in the, in the principles, um, the practices and patterns, there are many, these are just a small subset of some of those practices and patterns.

00:14:51

All right? So for this data management, uh, solution that system in which we were trying to use as a lighthouse, um, case for transformation to, uh, reduce that, that, uh, that lead time and to increase the quality we started with this chartering, we took about several meetings, maybe three or four hours, uh, which is important to align everyone on what the real focus is of, of that visor and getting the right people there. After we did that, we got into a room, this is pre COVID. So we were able to do this physically, uh, and, and, uh, do build out the current state value stream map. I'll show you a more readable view of this in a moment, but, um, people often ask, so what's your favorite vice-chair mapping template and tool and whatnot? Well, you're looking at it, it's a, it's a marker pens, it's whiteboard and it's sticky notes.

00:15:48

So, um, we've of course been able to do this remotely, virtually now, and, and we're doing quite well with it with several tools, one of them being lucid chart, but there's many other really good tools that you can use for that remotely. Um, but it's really about the interaction. And it's really about how you do the mapping as a team than it is about the templates and the tools. So here's another view of that, um, in a PowerPoint form. Um, so each of these blue items is a process step, the pink, uh, smaller post-its here are, um, impediments, bottlenecks, uh, pain points, challenges that we might want to address, but these are, this is what the current state looked like. And for each of the process steps, we have the process time, which is the, um, value add time. And we have the lead time LT, which is the elapsed time, the end-to-end time with all the weights in between.

00:16:46

So people come into a vice-chair map and they think, okay, well, let's improve the DevOps and agile aspects of, of what we do. Um, and each might come with their different viewpoints about what the most important thing to do is might be the, um, you know, automate some testing, uh, focus on, um, agile sprints, getting better at those, you know, velocity, um, maybe maybe improve the, the CI CD pipeline. Those are all potentially good things, but what doing the value stream map and what we, we, we saw here is the entire team cross-functionally could clearly see that if you want it to dramatically reduce this lead time, if you look at the first five or so boxes all the time that it takes to capture requirements, to concept reviews, create business case, um, do project approvals, and then staff the team for those projects, this by far, is taking up most of the lead time for the entire end to end value stream.

00:17:49

All that front end stuff is, is what the team discovered. Well, yeah, maybe we shouldn't focus first on these other items to optimize. Maybe we should really all attack that if we really want to achieve the goal, and that's the power guys, your mapping gets everyone to see that. So that was clear here. So this is where that term fuzzy front end comes in from the title of his talk. So this was from the book lean enterprise by Jess humble and Moleski, and O'Reilly, uh, probably my favorite original book on, on DevOps, on agile, on leadership and on change a really good book, but it, it outlines this in this picture where you see the middle in blue there, the agile team doing iterations, doing their sprints, putting together their, their, their testing and their development and iterations, um, doing really well, possibly with that and getting a lot of efficiencies and getting the right thing built.

00:18:44

But then you've got this fuzzy front end on the left, where there's a long, um, cycle of, of, uh, approval and budgeting and finance and prioritization and the PMO and their upfront planning and coordination that might be, um, as in our value stream for this case, that might be a really long period of time. You've got the short development, agile team dev test, uh, you know, uh, software development work. And then on the right this last mile, it would be very lengthy as well with integration with a lot of, um, you know, extensive user acceptance testing, um, passed to IP operations change management process approval. So what you get here is this water scrum fall aspects. I'm sure many will recognize this from our own organizations. So even though they're being really agile in the middle, the overall end to end lead time might be horrific.

00:19:42

And, and no matter what that team does to optimize their velocity. And that's where all the attention is, right. How do you get more velocity out of that team? How do you have you improve what that team does? But if you look at the overall end to end, it's, it's sometimes that fuzzy front end, that's the biggest problem. So Jonathan smart, uh, also depicted this, uh, in last year's DevOps enterprise summit. Um, and I think this was originally a picture from cross Leopold, but it's, again, this team celebrating how agile they are, they're in the middle. Um, when in reality, you've got these cadences up front that are monthly, quarterly or annually, and you've got these cadences on the, on the, on the downstream right side where we're monthly or quarterly. So yeah, they're so agile, but are they really agile when you look into, and so after we did that current state and came to all those conclusions, or let me just mention that in this, um, current state, you look at the bottom, right where the data block is, and you see that the process time is only nine weeks.

00:20:48

That's the actual value add work time, but the total lead time can be six months. So nine weeks or so of work in a six month timeframe in value-add work to a six month timeframe. So pretty big disparity, much of that was determined to be that fuzzy front end. So how do you go attack that? So, um, in our future state values for mat, which was step three, we laid out a what we want, what the ideal state to be, where we would have, um, budgeting set up annually, where we would have, uh, that then reviewed periodically, but have that team be formed, a cross functional full stack team, be long lived, um, as a product, as a product team. And then, um, do our, uh, uh, program increments and planning do our sprint work, but have that team pull from a single product backlog with a product owner, have that, have that backlog be the authoritative source where items could get put in there and reviewed on a regular basis as the business prioritizes and regularly, uh, so, so basic product model, but to get the whole team together, to align on doing this and seeing that, that was the critical part of the end-to-end value stream was huge.

00:22:11

So if you look at the process, the data block at the bottom on this picture, you see that the total process time was still the same plugged in nine weeks, but the total lead time, now it could be as short as 10 weeks or even less. So you reduce that disparity, not only from the fuzzy front end, fixing that and going more to a product model, uh, but also from other, uh, uh, fast feedback loops, test automation and other things that we identified. So all these purple post-its or some of the, uh, uh, countermeasures to get from a current state to the future state. So if you look at this, uh, in this, in this picture, you see the current state has all this front end part that takes four to six months. The future state eliminates that, and you can get rapid, uh, flow through the, through the, through the value stream.

00:23:04

So with all these, um, countermeasures that we came up with, um, we've got, uh, we did a prioritization process through a typical, you know, grid where you show the benefit from low to high of, uh, the execution ease from difficult to easy. And then the team collaboratively did these, uh, place these in the, in the appropriate spots. And then did multivoting, uh, to try to come up with an initial and initial, uh, improvement backlog. So just like a agile backlog of features, you create a value stream improvement, backlog of countermeasures that could get us to that future state. Here's a high level view of some of those improvement epics first and foremost, this project product shift. And I'll talk a little more about that, um, going from waterscrumfall to, uh, or this fragile, fake agile to, to more of a true agile model. And then the Kaizen process, which I talked about before, that's that critical process of continuously improvement.

00:24:06

So baking in value stream improvements into the regular sprints and having that be a priority, having, having everyone's eye on that end to end value stream that lead time, the outcome measures that we want from a value stream perspective, and then have that baked in so that the team is working those every sprint, those were the top three, and you can see some of the others below that. So, um, then after, uh, kind of working down this list, the, the, the, the primary shift was this project or product, so many success patterns that we'd leverage from what we did with, um, many other customers. And, uh, they worked through this, uh, building out the small cross-functional long lived, you know, T-shaped team, um, making sure they established a single backlog with the product owner as the afforded source of those prioritization. Um, and then working with the leadership team on fixed funding and getting approval for, for this, this, uh, application set to have fixed funding, and then periodic reviews with the management team, um, uh, making sure that the leadership team honored the backlogs that the backlogs were the, sorry, the backlog was the single source of that, and not have other things come in sideways into that.

00:25:27

And they're really important part of this broader transformation stemming from this, this lighthouse, uh, transformation item is to pivot the PMO organization. And I'll talk about that a little bit below that you can see some of the other items that are sort of the next steps and areas that they're, that they're still working towards our key resource, besides the experience our coaches have and, and work we've done with other customers on, and going from project to product, is this a white paper called the project to product, um, transformation. This was, uh, built out of from, um, it revolution out of the DevOps enterprise summit forum, a really good resource that we leveraged and, um, highly recommend it, um, that shift from a PMO traditional PMO to, to a, a new way of working, it was, was a key part of this transformation and continues to be.

00:26:23

So the traditional is more around project and program management, reporting status, milestones deadlines, you know, that red, green, yellow status of how things are working toward the plan. Um, a lot of governance and, and, um, focus on those dates, you know, meeting the plan dates and outputs, very familiar, very what we all kind of grew up on the shift of that PMO organization, including the shift of the way leadership does reviews and considers these things is more of a value enablement team. There's many names for it, but, uh, um, that's essentially what the shift is about. So rather than the project project management, it's coaching and enabling teams having that be the center, um, maybe gathering the leading and lagging measures and helping with that, but helping with inspecting and adapting toward the outcomes or the hypothesis of what the business goal is. So really focusing on, um, measuring those business outcomes, rather than just measuring the status of where are we on track, or are we on schedule?

00:27:28

So what were the resulting outcomes of this, this transformation of this product, um, over 50% decreased time to deliver so down where we can, where the team can get, uh, within two sprints of features developed and delivered, um, 370% increase in the, in, in the flow of, um, of completed stories. And you'll see, on the bottom, right, that at first there was a big investment or focus on the continuous improvement of backlog items as, as opposed to dominating by only the features. So this kind of goes part and parcel to Mick Kirsten's flow types, where you want to balance out the different types of work. And in this case, they, they emphasize during this initial transformation focus on the improvement, ethics, not just the feature efforts, um, more productivity at less costs, 170% more user stories at 19% less cost. And, uh, velocity increased deliver twice as fast through a 12 week, uh, pilot period, uh, 15% increase in user story delivery and, uh, uh, market increase improvement in consistency, which was important kind of the bottom line, um, change or, or critical success factor here is that the continuous improvement over time to date has averaged about 16% of the backlog items being continuous improvement items.

00:28:55

So that's, I think, uh, a good sweet spot that we've identified between 10 and 20% of time should be focused on these. So some takeaways, uh, not a one size fits all endeavor. Um, no kind of don't think of it as a standard dev ops or agile formula to change, but rather think of it as what's the value stream. What's the specific item in the value stream. That is the biggest bottleneck for this specific area. Second takeaway is knowing the baseline and using hypothesis to focus on an outcome measure. So what's that currently time, and what's our bogey, what are we trying to achieve? Um, the leadership engagement is key. Uh, some unlearning has required, um, kind of role changing from the traditional, where are you on your status? What's red, yellow, et cetera, to, um, helping remove impediments and, and driving that continuous improvement culture.

00:29:48

And then of course, looking end to end at the value stream and, um, consider that the fuzzy front end might be the key bottleneck. Um, here's a picture of us in the, uh, during the current state vice-chair map. And as one of my mentors and coaches from, from the past around vice through mapping said, don't fall in love with waster mapping fall in love with continuous improvement. So it's really not about the pretty map it's about the continuous improvement process and getting the team aligned on the, the, the key goals together. Um, lastly, we know, and we knew that having key coaches was critical. So we've developed a process for developing new value stream mapping, a new agile, new, new DevOps coaches across the organization to extend this and scale the transformation. So we have a process where we do shadowing, reverse shadowing, mentoring, and put, and this is, uh, a Kanban board within GitHub that we use for coach development. So in summary, I would say that huge success from this, um, the keys are to focus on value streams, um, to focus on the culture of continuous improvement. So this requires the leadership and also enablement, enabling team, uh, concept to help not only get the results, but get the team self-sufficient in building out their own continuous improvement process. And of course, lastly, look into end and don't forget to attack that fuzzy front end. Thank you very much.