Alexa Alley

I could stand up here for the next 25 minutes and teach you all how to host one of these value stream mapping workshops, but we're not going to be doing just that today. There are tons of books, videos, artifacts that can teach you how to host and facilitate one of these workshops.

But one thing that we've learned from doing these with five different businesses and multiple teams across those businesses is that you have to be flexible and iterate each workshop to fit the need of the individuals and the teams participating. There's no handbook that's going to teach you step by step how to complete a workshop in 100% of the situations that you face.

No two teams are alike, and while each team has similarities and challenges in what they're trying to face and accomplish, the way that these teams interact and their end result requirements are very different. The key to any successful VSM is aligning on a common goal and focusing on the journey to getting toward that goal, while worrying less about what the end result actually looks like.

During this time together, I'll talk through the benefits that we've seen at Hearst Business Media hosting these VSMs, how it can help to drive a DevOps culture, and how those changes have a positive impact across the entire organization. I'll also go through some tactical examples of workshops that we've conducted in the past with some of these businesses.

A high-functioning DevOps team is much like the crew aboard a ship. You must trust each other to do good quality work. And just like the sails can't be raised before you can pull the anchor, you can't deploy a product or write that product without clear requirements from the business.

Now let's go on this journey together.

It starts with the culture and the community, just like any DevOps initiative. What is the goal and the purpose of hosting this workshop for you, your teams, and the organization?

At HBM, we do these to increase visibility. We want to highlight and strengthen the DevOps culture that we're working to achieve across the whole organization. We want to build a stronger, more collaborative internal community across all job functions.

You want this community to allow visibility of work across the entire value stream. You want to have trust among the teams, as well as trust from the leadership. You want a culture that does not reprimand for failures, but encourages innovation, forward progress, and forward learning.

We also do these to identify bottlenecks or barriers to flow in the current workflow. We want to reduce friction points that currently exist. You can identify communication patterns.

According to Conway's Law, businesses create products and software that are reflective of the environments and the teams. If you create collaborative, high-functioning teams, your products will reflect that as well.

We want to showcase where there are tool interdependencies. We want to understand where work is sitting for approvals or at gates, where there are significant hold-ups or rework and inefficient processes, and we want to remove those.

These bottlenecks that you identify help to build a transformation plan and a business for the future that will get you to this high-functioning DevOps initiative and team.

But first you need to get buy-in. It's one of the most difficult things that we face before hosting these workshops at Hearst Business Media. You need interest from all parties. This starts at the leadership and goes all the way down to the individual contributors and members on a team.

You need to show them value in a way that is easy to understand for them.

For leadership, it's more tangible. How is this workshop going to help move the business forward? Is it going to get more customers? Are you increasing revenue, delivering more products more quickly? Does it improve revenue for your teams and get more sales?

For the individual contributors, it's intrinsic. What are they working on now that they haven't been able to before? Are they finally getting to work on that tech debt that's been sitting and building up, and they can finally decrease some of that? Are they working on a fun new project or feature that's been pushed back into the backlog because there are too many bug fixes or outages?

You want to get the buy-in from every single person before you can host this.

To do that, you need a champion. We have a champion in the form of two different people at Hearst Business Media. These people need to be leading the change for the business. The leadership and the teams participating need to trust, support, and encourage this person.

The first person is our internal champion. This is the person inside of the business who's really going to be fighting for this transformational change. They don't have to be a manager or an engineer or even a C-level executive, but they need to see the value for speeding up and transforming your current workflows for the business. They need to have demonstrated ability to innovate and improve their own processes, as well as the processes of their teams.

The second person is the VSM facilitator. For us at Hearst Business Media, we're objective members outside of the value stream who have no stake or opinion in the outcomes. Now, this isn't required by any means, but you need to have an objective stake in this when you're facilitating these workshops. You need to push these teams to make the right changes for the business.

They also need to be somebody who's comfortable to let the team know when discussion's getting a little offhand, and pull them back to the objectives and the tasks that we're working to accomplish during these two days.

These workshops start well before the first day. You can't go into a conference room with 20 people and have them understand why they're there. So you need to set these expectations.

When determining who needs to be present at these workshops, think of people who have a stake in the value stream. They need to have the authority to make necessary changes for their business and their teams. These members should be able to speak to the process and the time required to do those processes. If the management can't accurately do this, then somebody on the team should absolutely be there who can accurately speak for the rest of the team.

But that's not to say that only people who have the authority to make these changes should be there. Anybody who wants to be a participant in this and who wants to move the business forward and make changes for themselves and their teams should be able to be there and be part of this entire process. Nobody should be excluded from these.

You want to mentally prepare these teams for this workshop, and we host a short AMA, or an ask me anything. This gives everybody the opportunity to address concerns, ask questions, and give their opinion on what defining success looks like to them.

From the perspective of the facilitator, this gives you the opportunity to see how teams interact now, before you actually get into the room. So you can understand where there might be friction points between individuals or those teams, so that you can prepare ahead of time and understand where you might need to pull people back into the task at hand.

In our experience, this AMA is what really gets the C-level and the upper management teams bought into the process, and so they can really support it.

Once the team is completely informed and they don't have any more questions for the moment, we build out a charter. This charter sets the scope. It addresses the main challenges that you want to address during this workshop, during these two days.

You need to have a very specific value stream that you'll be mapping during these days. Is it going to be the SDLC process? Is it going to be your content release? Whatever it is, the entire team needs to be aligned on what that value stream is that you're mapping.

This charter should also have a desired deadline that you want to build out for this transformation plan. Are you hoping to implement these changes in six months, one year? However you decide to do it, it needs to be clearly stated so you have an objective to work toward.

All members who will be at the workshop need to be aligned and in agreement on the value stream. The facilitator needs to set these expectations for what you're going to be accomplishing during these two days. Day one is the current state. Day two is the future state and the transformation plan.

The team needs to understand that they'll be getting artifacts. I build out these artifacts and send them to the team to keep up, print out, put on their wall, so it's a constant reminder of what you've done and what we're working to achieve.

The team also needs to understand that they should have at least quarterly sync-ups. We recommend much more frequently. But they need to continue to revisit this and talk about where they are in their transformation plan.

We set a loose agenda as well to help guide the conversation along, but the real value comes from the collaboration in the room and getting these teams finally sitting together.

You need to set very realistic expectations. One workshop isn't going to change a habit that's been built for the last five, 10, 50 years. This is iterative. It needs to be revisited. It needs to be redone regularly. So the team cannot expect that one workshop is going to completely transform your entire business, especially with a business of 27,000 employees. Trust me.

But most importantly, this is blameless. There should be no finger-pointing for an individual or a team holding up the value stream. We're working to make this better, so you need to support and encourage these teams to work to making these changes.

Every participant in the room is on equal footing when you enter this workshop. Leadership is no longer executive leadership. They need to support and encourage the individual contributors, just like the individual contributors need to support and encourage the leadership.

Now, the fun part, you guys.

This is a current state map that we've actually done with one of our businesses. This is day one. What are you currently building?

We start day one by reiterating the prep work, redefining the scope, and the very specific value stream. Everything starts with the customer. When a customer sends in a request, how does work flow through the entire process, all the way back through to delivery?

You start this by building out the process cards. On the process card, you include what work is being done, what team is doing that work, as well as the process time, lead time, and percent complete and accurate.

You can include the process breakdowns as well for the more in-depth processes that you have in your current workflow. You should include the WIP, any queuing, batching that occurs in this workflow. And then you build out the tools and the information flow. How does work flow from each process up through your toolchain?

Now, we include lead time in days. We do it in days, and you include the weekends, because this is still a day that a customer does not have a functional product or feature in their hands.

When determining the efficiency rating, though, you should remove these weekends. You're not expected to be in the office 24 hours a day, seven days a week, so you don't want that to be included in your efficiency rating by any means.

We do process time in minutes or hours, depending on what works best for you and your workflow. This is actual hands on the keyboard, in meetings, writing emails, work being done on the process.

And the percent complete and accurate is the amount of time that the downstream work center can actually begin working without any further requirements, questions, expectations, definitions from the upstream work center.

This is really, really important to include on the current state and current day map, because you want to understand where there are bottlenecks and why the downstream work center needs these further requirements.

On this day, we focus on what. What is actually happening? We don't focus on why or how yet. This is all done on day two when you build out the future state map.

You want to make sure that you allow some flexibility still for open communication. That communication, though, needs to add value to the process at hand. You spend a lot of time mapping out this day. For us, it takes the full eight hours. You want to make sure that you have everything included.

This is the base of your future. This is where you understand what is actually happening in your workflow. And a lot of times, there are processes that the teams and management didn't even know still happened. This is your aha moment day, where the teams are finally collaborating, connecting with each other, and talking about what is happening in their current business, and how can we make this better.

This helps to find where there are friction points, where there are holding patterns, where the work transfers between teams. So make sure you get this done right and well, and that the business fully understands what is happening on this day.

You come in day two to build out the future state. This is a real future state map that we've done with one of our businesses as well. You build it in the same conceptual format with the process cards, any process breakdowns, information flow.

But this day, you do it with no constraints. This is your ideal world. If you could build out any workflow, what would that look like? And how would it help your business?

Now, of course, you have to bring it back down to reality. Everything's not going to be perfect after one value stream. And so that's where these stars and cubes that are numbered come into play. This is what builds out the transformation plan.

You take these cards and assign projects to them, or features, things that need to be done to get you toward this future state. The blue stars are JDIs, or just-do-its. What can be done really quickly, really easily, with minimal effort? Maybe it's removing somebody from an email. Maybe it's not sending that email.

The orange cards are Kaizen cards. Those can be done in a sprint. One to two weeks, requires some more manual effort and a little bit of planning and scheduling, but altogether, not too difficult to get done.

Then the project cards. The project cards are much more in-depth. Those require additional headcount. Maybe it's implementing and researching and buying a new tool, and then training on that tool. These take time to do, and they need to be noted very clearly on this day.

This is where you really focus on the DevOps transformation. This is automating where you can. This is building those cross-collaborative teams. You want to have the teams working together with minimal amounts of information flows and tool sets.

We take these JDIs, Kaizens, and project cards and unbiasedly map them from one to 10 in both value and difficulty. Once the team agrees project card 17 is a 10 in value but a 10 in difficulty, you take all of these numbers and you put them onto a heat map.

This heat map is the transformation plan. The team can take these cards, and based on how they were ranked, understand what is put into priority, what can be done right away to get us some good results most quickly for the business. What should be scheduled? This should be done in the next couple of months. What's put into the backlog, and what should be eliminated? What won't really be adding value?

Obviously, things with higher value and more difficulty are put into scheduled or backlogged, sometimes eliminated. But things that are high value and high priority are put into the priority section.

These should be done in the goal outlined by the mapping team in that charter. It's important to note that the work and timeline for completion is done by the mapping team and not the facilitator.

How you measure success can be very unique, and this should be defined by the leadership and the transformational teams when building out the deadline and their goals for completion.

How you measure success can be in the number of deployments. Is it in customer feedback? Maybe the number of defects. However that team decides to do it, it should be reflected in a very obvious way that shows value to the business and the teams, so that it can be represented and have hard numbers and facts when showing that these are providing value to everyone who's participated, to stakeholders, and the business.

Now, that's not to say that these all go perfectly smoothly. Nothing ever does. So we have challenges, and some of the more common ones that we've seen at HBM, and a big one, is disagreement on the averages or that sample set.

This is why it is so important to have such a clear value stream that you're going to be mapping and a very clear scope.

We use the 80/20 rule also when determining this. 80% of the time, what is the most accurate amount of time spent on one of these processes? We're not looking for exact numbers. You won't get perfection. You just want to identify what is the most often amount of time.

We see a lot of defensive posturing around the numbers as well. People tend to not want a negative number associated with their process card, but it's important to have these in the right spot and accurately represented, so you can identify where there is that bottleneck and how can the teams help each other to remove that bottleneck and get rid of that long lead time or that long process time.

There are also a lot of people who come into the workshop and feel that they don't have something to add, or maybe they're only shooting other people down. You want to make sure that everybody understands their values, their beliefs, their ideas, their opinions are heard, understood, and helping to move the business forward.

Every opinion and comment counts as long as it's adding value to the task at hand. We value all opinions and don't let anybody be a silent objector in this.

These value stream mapping workshops help to drive DevOps in any size organization. For us, it helps to iterate as the business and your customers change. It helps to collaborate with the members inside of your business who are in different teams, or maybe they're in different verticals in a different business altogether. It helps to identify where you can automate different processes.

You want to increase performance across the entire system rather than in one specific department. You want to increase feedback loops and communication, and build a culture that allows for experimentation, continual iteration, and learning.

Anyone can build this competency in your organization. It takes a lot of time, it takes a lot of practice, a lot of iteration, but you can do it, and it's awesome. It's one of the most beneficial and helpful things that we've been able to implement at Hearst Business Media to show value and help to drive this culture that we're really pushing for.

So I'd love to hear how you guys have currently done value stream mapping workshops, what questions you have. If you're thinking about doing it, please come talk to me. I'd love to learn from you guys, love to help you learn.

So thank you very much. That's all I've got, but I hope it was good.