John Ediger

Hi, my name is John Ediger. 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 DevOps/Agile transformation story and experience report about how we did this internally within DXC Technology.

So first, a little background on me. I am a DXC Distinguished Technologist and a DevOps/Agile Transformation Principal. So that means I work with large enterprise companies in helping them on their DevOps/Agile journeys toward business results. I also do this internally with our group. We do transformations 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 as an architect and a technology executive in IT and in R&D over the years.

So who is DXC? Where do I work? So DXC Technology is the world's leading independent end-to-end IT services and solutions company. 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 this slide, over $20 billion in revenue, over 6,000 enterprise customers, over 23,000 agile DevOps practitioners, and one thing to note is we do over 14,000 cloud application migrations per year. We were also awarded the Industry DevOps and Agile Leader recently. So that's who DXC is.

A little bit about where I fit in within DXC. So part of our DevOps/Agile enablement offering, we have a group that focuses on building out this enablement and helping customers and internal groups with their DevOps/Agile journeys. And so you often think of enablement, or some people think of enablement as tools and helping with methods and tools for Agile or DevOps. We know that that's only the 20%, and it goes a lot further than that. So this sort of depicts what we do and how we help, and this fits into this transformation journey that I'm talking about in this experience report. So all these elements here of this enablement are targeted for our customers with continuous feedback loops, as well as internal within DXC. So kind of going around the circle here from the top counterclockwise, what makes this offering up? What are some of the things that we do to help with these transformations? First, there's these dojos. So we have world-class dojos that we started, we designed back in 2015. You may have heard other presentations by DXC and experiences with DXC on our dojos. So these are immersive, hands-on, coaching-led sessions to help accelerate the DevOps and Agile journeys. We've also branched out and made other types of dojos, such as executive-level green belt DevOps and Agile dojos, as well as we've created some self-paced online persona-based training modules, and we've made those open source recently. So you can find those yellow belt dojos online in GitHub. Value stream mapping has become a very core part of the transformation repertoire, if you will. We will talk more about that. I'll go into that as part of this experience report. We build out patterns. This is key. We build out patterns across our offering, across DXC, document those in our GitHub repos, and continuously improve those patterns. And these patterns are everything from enterprise transformation, DevOps transformation patterns, to team patterns, to technical patterns on adopting DevOps and Agile for results. Consulting's a key part of this. So 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 a key part 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 momentarily. 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 experience reports, we do a very similar format, and we do that internally across our company every two weeks. We've been doing that for about three years. And last but not least, coaches. That's the heart of what transformation is about, having enablement teams with key skilled coaches and building out more coaches across an organization is key.

So with that, in this experience report per Gene Kim's format, talked about the organization, talked about where I fit in. So now let's get into the business problem that we want to solve, 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. It's a large IT organization. The goal was to get to faster lead times. So from the business request, business need, all the way out to valuable features in production, how can we increase that? How can we 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 value streams, but to scale out that transformation across the large organization. So using an initial lighthouse application or an area that we have something 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 initial application, which was around managing master data across all IT systems.

So how this was approached stemmed first and foremost from a set of patterns. 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 kind of leads to the approaches that our teams are taking, is that an anti-pattern typically you see is modernization for modernization's sake, or trying to get to some maturity level, doing DevOps or Agile for the sake of DevOps and Agile. Rather, the approach that is more effective, of course, is to focus on the business outcomes. Treat the DevOps and Agile 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 reach this checklist of DevOps items.

The second big anti-pattern is big bang. 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, small efforts with feedback loops, assess, adjust, get value as you go, and reach the outcome goals through iterations rather than trying to do a big bang change.

The third transformation or the third anti-pattern is around technology and methodology focus. In other words, focusing on only the technology or the Agile ceremonies and methods rather than looking holistically and focusing on how teams work, the culture, the leadership, 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 that we worked on, is this thinking of DevOps and Agile as a one-size-fits-all venture. 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 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. And this is where value stream mapping really comes to play.

So a quick overview on what that is for those who aren't familiar with value streams and value stream mapping.

The value stream is 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? All those steps, those handoffs, those processes and systems that it takes to go from beginning to end. On the bottom left is a textbook example of a value stream map, a current state.

The power of value stream mapping is in seeing the end to end, in 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 optimize their silo, we look end to end. How do we make sure we get the right value at the right speed flowing through the value stream together as one thing, rather than each having their own little parts? Very powerful.

And I would add that the mistake a lot of teams make in doing value stream mapping is they think of value stream mapping in the traditional sort of classic value stream mapping lean perspective. It definitely leverages lean, but we like to look at it more from the perspective of software being different and looking at it from maximizing the flow of software, which might be different from the old manufacturing lean way of looking at things. There's several idiosyncrasies around software, things that you can do with fast feedback loops, with flow, 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 way we like to look at value stream mapping.

Okay. So the way we approached this business challenge, this goal, is by running through a starting with the value stream mapping process.

So we use a five-step process.

The first being the charter, the most important step, kind of going through what is the scope, what are the goals? What is 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 workshop. So step two is the current state value stream map, documenting what is and getting everyone to look objectively at how things actually work. Step three is the future state value stream map.

From there, step four, we take what those countermeasures, what those hypotheses would be of what we could do or 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.

And lastly, step five, the most important step, which you can throw away all the other steps if you don't do that, that's this Kaizen process of continuous improvement. Executing on those countermeasures, implementing something against the goal, assessing, adjusting, and then targeting the next thing and going through that loop. That's the secret sauce of DevOps and Agile transformations. It's doing that step five. And then lastly, you'll see the pyramid there in the middle. You might recognize this from other DXC presentations. This is kind of core to our whole approach of DevOps and Agile, and let me just walk through that real quickly. So this pyramid represents kind of all the different aspects of DevOps and Agile. Often people look at the tools, which is the top part of this, as the most important. Tools are, of course, very important, but probably the least important of all the layers of this pyramid for DevOps/Agile transformation. So more important are those practices and patterns that underlie it. More important than that are 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. They're more visible. Also, they have the least impact generally. As you go down to the bottom, these are the things that are the least visible. They're really hard to do. These are the harder things to change, but really important and have the biggest impact. So looking across all of these is important, not just one or two layers, and paying attention especially to the bottom layers. And you'll recognize some of the mindset and culture items, and you'll recognize the three ways and the principles. The practices and patterns, there are many. These are just a small subset of some of those practices and patterns. All right. So for this data management solution, this system in which we were trying to use as a lighthouse case for transformation to reduce that lead time and to increase the quality, we started with this chartering. We took about several meetings, maybe three or four hours, which is important to align everyone on what the real focus is of that value stream 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 and build out the current state value stream map. I'll show you a more readable view of this in a moment. But people often ask, "So what's your favorite value stream mapping template and tool and whatnot?" Well, you're looking at it. It's marker pens, it's whiteboard, and it's sticky notes. So we've, of course, been able to do this remotely, virtually now, and we're doing quite well with it with several tools, one of them being Lucidchart, but there's many other really good tools that you can use for that remotely. 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 of the tools. So here's another view of that in a PowerPoint form. So each of these blue items is a process step. The pink smaller Post-its here are impediments, bottlenecks, pain points, challenges that we might want to address. But this is what the current state looked like. And for each of the process steps, we have the process time, which is the value add time, and we have the lead time, LT, which is the elapsed time, the end-to-end time with all the waits in between. So people come into a value stream map and they think, "Okay, well, let's improve the DevOps and Agile aspects of what we do." And each might come with their different viewpoints about what the most important thing to do is. Might be automate some testing, focus on Agile sprints, getting better at those, velocity, maybe improve the CI/CD pipeline. Those are all potentially good things. But what doing a value stream map and what we saw here is the entire team cross-functionally could clearly see that if you wanted to dramatically reduce this lead time, you look at the first five or so boxes, all the time that it takes to capture requirements, do concept reviews, create business case, 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. All that front-end stuff 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 of value stream 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 this talk. So this is from the book "Lean Enterprise" by Jez Humble and Molesky and O'Reilly. Probably my favorite original book on DevOps, on agile, on leadership, and on change. A really good book.

But 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 testing and their development in iterations. Doing really well possibly with that and getting a lot of efficiencies and getting the right thing built.

But then you've got this fuzzy front end on the left where there's a long cycle of approval and budgeting and finance and prioritization and the PMO and their upfront planning and coordination. As in our value stream for this case, that might be a really long period of time. You've got this short development agile team dev test software development work. And then on the right, this last mile could be very lengthy as well with integration, with a lot of extensive user acceptance testing, pass to IT operations, change management process approval.

So what you get here is this water-scrum-fall aspect. So I'm sure many will recognize this from their own organizations. So even though they're being really agile in the middle, the overall end- to-end lead time might be horrific 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 improve what that team does? But if you look at the overall end-to-end, it's sometimes that fuzzy front end that's the biggest problem. So Jon Smart also depicted this in last year's DevOps Enterprise Summit. And I think this was originally a picture from Klaus Leopold, but it's again this team celebrating how agile they are there in the middle, when in reality you've got these cadences up front that are monthly, quarterly, or annually and you've got these cadences on the downstream right side where they're monthly or quarterly. So yeah, they're so agile, but are they really agile when you look end to end?

So after we did that current state and came to all those conclusions-- Oh, let me just mention that in this current state, you look at the bottom right where the data block is, and you see that the process time is only about nine weeks. 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, in our future state value stream map, which was step three, we laid out what we want the ideal state to be, where we would have budgeting set up annually, where we would have that then reviewed periodically, but have that team be formed a cross-functional full stack team be long-lived as a product team. And then do our program increments and planning, do our sprint work, but have that team pull from a single product backlog with a product owner, 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-- So a 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.

So if you look at the data block at the bottom on this picture, you see that the total process time was still the same, five to nine weeks, but the total lead time now 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, but also from other fast feedback loops, test automation, and other things that we identified. So all these purple Post-its are some of the countermeasures to get from the current state to the future state. So if you look at 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 flow through the value stream.

So with all these countermeasures that we came up with, we did a prioritization process through a typical grid where you show the benefit from low to high, the execution ease from difficult to easy, and then the team collaboratively placed these in the appropriate spots and then did multi-voting to try to come up with an initial improvement backlog. So just like an Agile backlog of features, you create a value stream improvement backlog of countermeasures that could get us to that future state.

So here's a high-level view of some of those improvement epics. First and foremost, this project to product shift, and I'll talk a little more about that. Going from water-scrum-fall, or this fragile fake Agile, to more of a true Agile model. And then the Kaizen process, which I talked about before. That's that critical process of continuous improvement. So baking in value stream improvements into the regular sprints and having that be a priority, 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 then after working down this list, the primary shift was this project to product. So many success patterns that we leveraged from what we did with many other customers, and they worked through this building out the small cross-functional long-lived T-shaped team. Making sure they established a single backlog with the product owner as the authoritative source of the prioritization. And then working with the leadership team on fixed funding and getting approval for this application set to have fixed funding and then periodic reviews with the management team. Making sure that the leadership team honored the backlogs, that the backlog was the single source of that and not have other things come in sideways into that. And a really important part of this broader transformation stemming from this lighthouse 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 still working towards.

A key resource besides the experience our coaches have and work we've done with other customers on and going from project to product is this white paper called "The Project to Product Transformation." This was built from IT Revolution out of the DevOps Enterprise Summit forum. A really good resource that we leveraged and highly recommend it.

That shift from a traditional PMO to a new way of working was a key part of this transformation and continues to be. So the traditional is more around project and program management, reporting status, milestones, deadlines, that red, green, yellow status of how things are working toward the plan. A lot of governance and focus on those dates, meeting the plan dates and outputs. So 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 that's essentially what the shift is about. So rather than the project management, it's coaching and enabling teams, having that be the center. Maybe gathering the leading and lagging measures and helping with that, but helping with inspecting and adapting toward the outcomes, toward the hypothesis of what the business goal is. So really focusing on measuring those business outcomes rather than just measuring the status of are we on track or are we on schedule.

So what were the resulting outcomes of this transformation of this product?

Over 50% decreased time to deliver, so down where the team can get within two sprints of features developed and delivered. 370% increase in the flow 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 opposed to dominating by only the features. So this kind of goes part and parcel to Mik Kersten's flow types, where you want to balance out the different types of work. And in this case, they emphasize during this initial transformation focus on the improvement epics, not just the feature epics.

More productivity at less cost, 170% more user stories at 19% less cost, and a velocity increase delivered twice as fast through a 12-week pilot period, 15% increase in user story delivery, and a marked improvement in consistency, which was important.

Kind of the bottom line change 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. So that's, I think, a good sweet spot that we've identified. Between 10% and 20% of time should be focused on these.

So some takeaways. Not a one-size-fits-all endeavor. Don't think of it as a standard DevOps 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 hypotheses to focus on an outcome measure. So what's that current lead time and what's our bogey? What are we trying to achieve? The leadership engagement is key. Some unlearning is required, kind of role-changing from the traditional where are you on your status, what's red, what's yellow, et cetera, to helping remove impediments and driving that continuous improvement culture. And then, of course, looking end to end at the value stream and consider that the fuzzy front end might be the key bottleneck.

Here's a picture of us during the current state value stream map, and as one of my mentors and coaches from the past around value stream mapping said, "Don't fall in love with value stream 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 key goals together.

Lastly, we know and we knew that having key coaches was critical, so we've developed a process for developing new value stream mapping and new agile, 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 this is a Kanban board within GitHub that we use for coach development.

So in summary, I would say that huge success from this. The keys are to focus on value streams, to focus on the culture of continuous improvement, so this requires the leadership and also enablement, the enablement team 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 end to end and don't forget to attack that fuzzy front end. Thank you very much.