Alexa Alley

Last year, I spoke in San Francisco about how to get started. I'm going to touch a little bit on that today, but this is going to be more about how you continue the progress, how you continue the movement after you complete a value stream, to continue to show the value that these can have and the progress, and how to actually keep traction and keep the business in line with moving forward on that.

Like Polly said, we've done 14 of these. He's my co-facilitator, and we've done them in healthcare and transportation, from software development lifecycle, product teams, implementation, content creation, distribution, and delivery.

That's not going to work.

So start with: what is your goal? What are we trying to accomplish with this? You have to be very clear about what the goal and the objective is before you even go in and start a workshop. You have to have your champion on board with this, agreed on this, and the leadership absolutely needs to understand what your goal is going to be.

Are you trying to deliver more quickly? Deploy more features, products? What is that? And make sure that everybody in the business and on the mapping team is aligned with that common goal.

You want to make sure that everybody has agreed and committed to maintaining that momentum as well. It's not a one-, two-day, three-day process. This continues far, far after the actual workshop happens. So make sure that everybody is committed to maintaining that and committed to doing the additional work that's going to come out of these, because there will be work that comes out of this. A lot of work also. But take it in baby steps, too.

And make sure that you're creating a way to drive value from those outputs. The outputs are what's actually been created: what's the new product that you've made, or the new project that you've implemented, the new tool? Make sure you're showing value from that new output that's been created from this workshop, and make it visible.

And you want to make sure you drive outcomes from those outputs. Are you deploying more frequently now because of those new products, because of those new features that have been implemented? And how are you measuring those outcomes? All of this should be visible, tracked, and measured in some way so that you can continue to show the business that you're making progress with it and moving forward.

And it all comes back to the business. The business needs to see the value. You should stack-rank your transformation plan to align with the business value and the business goals. If the business wants to make more money, sell more software, sell more product, whatever it may be, make sure that your transformation plan is aligned with all of that and that the business understands what your transformation plan is and how you choose to tackle them, and in which order, so that they can continue to support and fund the idea and the process and the transformations.

If you don't have support from your leadership, it's not going to work. It's going to stall out and it will die, and these two or three days that you've spent in a room with some of the top people in your company and your business were a wasted three days. Leadership 100% needs to be bought into this and needs to understand that this is going to take time, it's going to take people's time, people's work, and this is not an overnight change. It's a long, iterative process and should be studied and visible to them.

You should help them understand the impact and showcase the impact of all of that change as well. We use metrics: lead time, process time, percent complete and accurate. Make all of these visible to the leadership. This is what they want to see. They want to see the numbers. How is it changing? How is it making their business? How are their teams functioning better?

And present and measure in a way that's aligned with that company's success. Are you deploying more frequently? Are there fewer bugs now because of these changes that have gone in? Again, what does the business want, and how can you show them that this is making the forward progress and change that you got them to support in the beginning? If you don't come back and show the business the value, again, it's going to stall out.

So we start with the current state. The current state is incredibly important, and we spend an entire day mapping this out.

So how does it help? Why do we spend an entire day on what your current state looks like? We want the current metrics and measurements. What is your lead time? How long is work sitting before another team can actually get there? How much work is actually done versus that lead time? And how often can the upstream work center start working right away?

Make all of these very understandable and visible, and make sure that the team agrees on that also. These efficiency ratings, understanding the bottleneck: where is the biggest bottleneck, and how do you address that biggest bottleneck first?

If you're not addressing the biggest bottleneck first, you're just going to create more bottlenecks. You're going to be feeding the funnel too quickly at one end, or the team behind the bottleneck is going to be sitting twiddling their thumbs. So address that biggest bottleneck first.

And we focus so heavily on this because if you don't understand what you're doing now, what's wrong now, what challenges you have right now, you can't build a future that's better. You have to really understand these metrics.

It's a cultural development cycle as well. You have these teams sitting together in this room who usually don't. Get them all to talk to each other, and maybe they'll understand more why there is that bottleneck, why they don't get work as often as they'd like, or why they aren't delivering more quickly because the other teams can't work right away.

Building this cultural development between these teams has been by far the most beneficial thing that we've seen out of these, and getting these teams to finally talk to each other and understand where those pain points are and how they can help each other now because they understand that pain and those friction points.

We agree on the challenges that we're facing now. From having these people together, from building this culture and breaking down these silos, everybody can agree where the biggest bottleneck is. The math, the numbers don't lie. So you understand where that really is and where the entire team can help to bring it all together and help make one process better, so that down the line, they get support and buy-in from the other teams to help them with their problems as well.

Then we go into the future state. Understanding the future state is just as critical as the current state. What are the challenges that you're really trying to fix with this? That bottleneck, those efficiency ratios, where's the holdup? Why are teams not talking to each other?

We want to greenfield this. We're going to build our ideal workflow from scratch. We start over with a clean piece of paper, and in some cases, if the teams are a little too combative in looking back at the current state map, we'll take it down and let them build the future in any way they want. You, of course, have to bring it back to reality a little bit.

That's where the process mapping comes. You build out the projects, you build out the Kaizens, the just-do-its. You make it a realistic goal after you greenfield it. How can we get these teams to actually be where they want to be to make sure the business is moving forward the way that they want?

Measure and metric everything. We take lead time and process time on these as well. What do we want the process time to be? Realistically, what do we think we can do in development? If it's a 20-day lead time right now, how can we make it 10?

Make those measurements visible as well. Put those up in the middle of your cafeteria or in the dev bay, wherever it may be. Make sure that those metrics and your goals, your ideal workflow, is visible to everybody in the business, not just the mapping team, not just leadership. Everybody should understand what you're trying to do and how this one group of people, maybe it's the SDLC, maybe how they can help the content team or the product team.

Maybe they'll have interest now because they see how much better things are going for them. Make it very visible. This should be visible, and that's how you continue to get buy-in from the business, and that's how you get other teams interested in doing this and helping to support you.

And again, it's cultural development. These teams now get to sit together and build something from scratch that's theirs, and they all worked together to make it possible, and they're all going to continue to work to make it possible. Building this culture is really, really key to making sure that these are successful.

And then we do the transformation plan based on that future state. What are the projects that need to happen to actually make it work? What are the things that need to happen? And you stack-rank that with the business again.

We do these unbiasedly in both difficulty and value for the teams and the business. Rate them from one to ten. How difficult do you think it will be, and what is the value that everybody is going to get from it? And make them very clear objectives.

This isn't going to happen overnight again, so make sure you have these objectives written out in a month. What's something small that we can get done that will make this much better? Three months out, what's a project maybe that can be completed and remove that bottleneck? Six months out and a year: in a year, do we hope to be completely in this future state? And what are the tactical things that we need to do to get there?

And measure that success. Measure the new lead times, the new process times. Go back to your current state and change them as you're updating these process blocks and these process cards.

And revisit it all the time. When you complete a project or a Kaizen or whatever your objective was to complete, go back and revisit the map. Re-walk the entire thing. Since you've already done it, it should be quick to go back and re-walk this. Spend an hour a month, even if that's all that you can commit to, but make sure you revisit that map.

That's why it's important to keep it visible so that the leadership and the other teams can see where you're making these changes and how it's improved. Or maybe it hasn't improved, but how can other teams help you to make it better? Maybe they've done something that they think would help. This visibility gets traction in other teams wanting to help and be part of this as well.

But there's resistance to change, right? This is a huge project, a huge process that needs to be implemented. The actual workshop, while it's only three days, it's a year at least of work that comes from this.

So the biggest resistance that we find is mostly cultural. What are the business constraints? Maybe the business doesn't want to give you money to actually go and do all of this thing. They've already submitted their budget for the year. So how can you do things that don't require a ton of money? What are the things that you can implement and change now that are already part of your budget? Maybe you've already bought a tool. How can you make that tool more efficient for these teams?

How do the individuals on a team react to this? Make sure you have your champion, your person who's really going to fight for this entire process to move forward and work. Without a champion, it's not going to help either, and it's not going to work. And the leadership needs to really, really trust this champion also. It goes to the leadership.

Again, if they're not bought in, don't even bother. Don't bother, because the leadership has to support the change that you're trying to implement.

And fear. Everybody's afraid of change. Heck, I'm terrified right now, and I'm in front of 100 people. But you have to make yourself vulnerable in these situations. You have to understand what that fear is, why are you afraid, and how can you negate some of that fear? How can you make it better, and how can you show that? And that's with the metrics. Make sure you're measuring it so you can actually show what the success has been.

And process and tooling. You guys have processes and tools in place that have been there for 10, 20, hundreds of years maybe, depending on how old your company is. It's hard to change some of those workflows. They're embedded in the team and the culture. So you really have to work to understand and make those small changes.

Don't rip it out and completely rebuild it all at once. That's terrifying. That's going back to the fear, and people won't like that. The business won't react well to that if you rip something out that they've helped build and have supported since day one. See small changes.

And what are the switching costs with it? Again, the budgeting. Make sure you have an understanding of what can be changed with little money or no money with the tools that you already have to minimize what those switching costs would be up front, so you can show that value and get more budget from the business later on.

And knowledge. There's so much knowledge with these vendors. There's lock-in with these vendors. So offer training to people. Offer pair programming. Offer them ways to expand the knowledge base to remove a lot of that fear. That's a lot of the reason there is fear. They have knowledge in these workflows, in these systems, in these tools and processes.

So help them with that. You have to make sure that the entire team understands that they're not going to be fired, they're not losing their job because of this. You want to make it better for the individuals and the business as a whole.

So how do you ensure success? We do PDSA or OODA loops: plan, do, study, adjust. You can do this with planning your metrics and really allotting time to change. Make sure the managers and the business and the individuals understand that they'll have a couple of hours a week, a few hours a month. Whatever the business and the managers can allot to them is really key.

And let them block it off on the calendar so no meetings happen. This is really important to make sure that you're allotting the time for this as well. It's a big upfront investment, and so the time to change is critical.

And start with those small wins. Maybe don't go straight for the big project. Start with something smaller inside of that project that can really help with the bottleneck, but not completely remove it. You need to make sure that you're measuring this, studying it, and adjusting as things continue.

It goes back to recording everything. Are you deploying quicker? Are there fewer bugs? Maybe there are more bugs. Why is that? If you're not recording it, you don't know.

And make those achievements very visible. Again, put it up on the board that you've mapped. Make this open so everybody can come and look at it and get that executive buy-in. That's how you get success out of these. And the team. The team has to be bought in as well. It's not just leadership.

But what if it fails?

Good.

It means you tried. It means you've done something. Everything fails sometimes. We've all failed at some point in my life. Your life, my life. We've all failed sometime, right? But that's how you grow. That's how you make things better. That's how you get to those successes.

Readjust your goals. It goes back to those loops. If it failed miserably, maybe it blew up. Maybe your whole production system went down. That's not good. Do this in a test environment first. But readjust it. What went wrong? With those metrics, it can help you to understand what did go wrong.

And focus on those easy improvements. Again, those small wins will help eliminate the failure. Start small. If something small fails, it's easy to fix. It's easy to redo. So make sure you're not doing a huge, big-bang improvement right out the gate. The business, the teams, everybody really needs to understand and see how even just a small change can make it better.

There will be failures. We've seen failures with some of the teams that we've done, but we've gone in, we've remapped it small with them, and come out with another project, another plan, another goal to work toward. And make sure you're committing to continuing that success with them, and committed to helping them improve.

As facilitators, we don't help with the entire transformation plan. The mapping team should really do that. And the mapping team making this plan, moving forward with this, is how you make sure it doesn't fail, because everybody's bought in. They've gone to their management. They've said, "It's not going to be 100% right away." And that should be very clear to management as well.

You have to take risks. This is how it happens. You rework the plan. You revisit these all the time. All the time. We set up monthly meetings with our teams to go through and review what's worked, what hasn't, what can we do better, what's changed.

Maybe you completed a project and now you don't need to do something else because it solved two problems that you didn't even think that it would. This is why you measure it. This is why you study it. But you have to continue to visit this and work the plan and work with the team and the management.

We have to be disruptive for these. If you aren't disruptive, if you aren't willing to take risks, make a change, put your neck on the line a little bit, this isn't going to change. This isn't going to happen. So make sure you're taking those risks. But make sure they're calculated risks. Don't do something crazy that hasn't been thought out. It has to be calculated. These have to be clear goals and objectives.

We're always looking for ways to improve. We do surveys after the end of them. We talk with the teams. Every single workshop we host is completely different. Team dynamics are different. What the business needs to see, what they want is completely different. So make sure you understand that going in, and make sure your end goal is aligned with that.

If you guys have done these workshops, I would love to hear what you have done to be successful. If you're looking to get started, please come talk to myself. Polly would love to talk to you also. We're here to help. We're a DevOps community. That's what we're here for. So if there's anything that I can do, if you'd like more information on any of this, please reach out to me.

I'm on Twitter, LinkedIn. It's Alexa Alley. But come and find me. I'd love to talk to you guys. Thank you.

If you guys have questions now, I don't know if we have time for questions. I think we're right at about 25 minutes. But I will be around.

So thank you guys very much. I hope this has been beneficial, helpful. Have a great conference.