In this episode, I am presenting our teams approach to lean product and process development events.  This was a presentation I gave at the LPPDE virtual conference last month. 

You may be wondering why we haven’t been posting regular episodes…we are preparing to launch season two this next year.  Stay tuned for more amazing podcasts as we kick off the new year. 

About the LPPDE:

The Lean Product and Process Development Exchange, Inc. is a nonprofit organization created to foster opportunities to grow and share the knowledge, expertise and experiences that help organizations use lean product development to dramatically improve product development performance.

The LPPDE conferences are organized roughly yearly in both Europe and North America. These conferences are the motor for the flow of knowledge about lean in the product development context. We explicitly call our conferences “Exchange” – because that is what we think is the best moderator for learning: listen, experts, see peers, discuss, learn from best practices from others and participate in workshops, that are offered at introductory as well as advanced level.

Many participants of LPPDE conferences return because they know: whenever I visit an LPPDE conference, I am sure I will return with a high number of great ideas, excellent examples, and practical tips to continue my journey on the lean path in product development.

Check them out at www.lppde.org

Full Transcript:

Patrick Adams  00:01
Welcome to the Lean solutions podcast where we discuss business solutions to help listeners develop and implement action plans for true Lean process improvement. I am your host, Patrick Adams. Hello, and welcome to the Lean solutions podcast. If you haven't noticed, we've been a little scarce on publishing episodes of the lean solutions podcast. Well, there's a reason for that, we're actually building up and getting ready to launch Season Two of the lean solutions podcast. So I'm excited for all of you to be part of that in 2023, as we get back to consistent regular episodes of some of your most favorite guests, similar to what we've had in the last few years. But also, we're going to be reaching out to many new guests, who are helping to promote lean solutions around the globe. So look forward to that. But today, what I'd like to do is I'd like to play a recording of a summit that I recently spoke at the Lean product and process development exchange is a nonprofit organization created to foster opportunities to grow and share the knowledge, expertise and experiences that help organizations use Lean product development to dramatically improve product development performance, you can check them out if you go out on the web@ipd.org. I recently spoke at their virtual Summit, and I spoke on the topic of how to develop your lean product and process development process, utilizing a Kaizen Event focus. So it's a this is a great opportunity for you, you to just listen in and hear a couple things about how we at lean solutions, deploy Lean product and process development into organizations utilizing the Kaizen Event approach. So I hope you enjoy this episode of the lean solutions podcast

01:58
and a bit stressed, Patrick, but I am really, really glad about this presentation and that you are here with us because it is a very interesting topic, I think we can learn a lot. So Patrick Adams, please.

Patrick Adams  02:14
All right, well, thank you again. And I appreciate the opportunity in the time to come and present to all of you. And I'm looking forward to this presentation. I think I've listened in on a couple of the presentations prior and and definitely a lot of really, really great content coming your way. And just I appreciate the opportunity to be part of it. So thank you for having me. For those of you that are note takers, I always like to give kind of a few bullet points when I run through a presentation like this on different things that I'll be talking about. So if you are a note taker, we will be hitting on Lean product and process development very briefly, only because I know we have a number of experts in the room. So I'm not going to spend a lot of time on that. But I think it's important, as we talk about how we run lean product and process development events, how we facilitate. I think that just the initial definitions in the way that we establish a kind of level set understanding of Lean product and process development in the beginning of an event is very important. We also I want to cover with you lean product and process development event logistics, how we run an actual event, helping teams organizations develop their Lean product and process development process, again, for many different size organizations in many different industries. So I want to run through some of those points. And then I also want to talk about visual management, and Obeida and how we utilize visual management to help sustain the work that's done during a Lean product and process development events. That's what we're going to talk about today. So again, for the sake of this presentation, I'm not going to define Lean product and process development for all of you. However, in facilitating a Lean product and process development event, we do have team members that join us who are not familiar with Lean product and process development. So it is important that we take the time upfront during an actual event to level set and define what Lean product and process development is, as well as the process that we're going to go through to actually help them develop their Lean product and process development process for the organization. One of the things I do want to mention here though, is I do like to mention Alan Ward study of the Toyota production system, where Ward said that Lean product development seeks to address issues such as reduction of long development cycle times, reducing high costs of development, the need for more innovative solutions, reduction of production costs, and then even redevelopment cycles. Lee Lean product development stands behind the philosophy of not letting perfection get in the way of progress. Right? And it leverages it also leverages that Pareto principle that 20% of a product's features will most likely deliver 80% of the benefits that are sought out by customers of that organ of any organization. But Alan Ward wasn't the only expert to study and promote Lean product development. Obviously, we've heard from a number of people today and and I'm sure you'll hear from many people in the future that consider themselves experts on Lean product and process development. But I do want to mention and cover or just touch on two people that I think are key in really understanding Lean product and process development. This is Tim Schipper. Tim is actually a friend of mine. He's the author of innovative lean development. He works in West Michigan for a large manufacturing company that we do a lot of work with. And Tim actually defines Lean product development by some pretty simple key points, he says that we need to optimize the value equation and the product value. And then he gives us these nine recommendations, which I think are always key, I've actually had Tim come and speak at a couple of our events and kind of walk the teams through during the first day, which I am going to give you, I'm going to show you an agenda of what an event looks like. But during the first day, we always like to have speakers, like Tim come in and actually talk about, you know, some of the learnings that they've had in deploying Lean product and process development. So in talking with the team, Tim gave nine recommendations for any organization looking to adopt Lean product development. The first one was that knowledge sharing is key, he suggests that finding a way to share learning across the enterprise is so important, and that basically, we shouldn't be trying to reinvent the wheel, you know, every time we have a new product that's that we're trying to develop or a new product that's, you know, being rolled out to the to, to our customers, we should use our past learnings to accelerate the process whenever possible. Number two, we want to spend more time learning upfront, I heard a little bit of that already today. But this is where those rapid learning cycles come in. The more experimentation, the more prototyping, the product testing that can be conducted upfront, the better, right. And then number three is don't fear failure. This is a big one, especially for organizations. Here in the US, we have traditionally have many organizations struggle with fear based cultures. And you know, a lot of individuals struggle with the idea of experimenting and trying things, you know, with the possibility of having failure, right. So that's, that's a, an important one to touch on. Number four developing goals upfront. So understanding and knowing what we're looking for upfront and looking at that from the customer's point of view, so voc, as early as possible. Number five, he's he talks about defining the abilities, which was always really confusing to me when he first rolled that out, but some examples of that are words like durability, or flexibility. And then also understanding what are the non negotiable non negotiable items that will ensure success for that particular product? We don't want to move ahead without completing work upfront, right. So we don't want to, I've heard, you know, different questions and comments about phase Gades. Obviously, if we hit a phase gate, and there's certain work that hasn't been completed, we don't want to move ahead, we want to make sure that everything is complete, prior so that we can move ahead, knowing that the work that we're that we've done is, is ready and complete to move ahead. Number seven is allowing groups to work in parallel. Number eight is mapping out and identifying key stakeholders and key decisions. And then number nine is focusing on the product up front. So again, the question is, how do we do all of this in an event? I'm sure that's what you're wondering. It's not the norm for, for a organization to conduct a, you know, an event to develop their Lean product and process development process. So how does that actually happen? Well, this past year, I actually met with Dr. Jeff liker, and we discussed his book designing the future, which, which is, it was new, I guess, at the time, it's not new anymore, but he and Jim Morgan wrote about how Ford Toyota and some of the other world class organizations use Lean product development to drive innovation and transform their business and Dr. liker explained to me that Lean product development is a system and during their research at the University of Michigan, which was concurrent with the with work that was done and done at Harvard, a series of research studies under undertook and resulted in deeper understanding of specific practices and tools that were used at Toyota. And again, you some of you may be familiar with, with these. But you know, one important point that Dr. liker made was that copying Toyota wasn't the right way to go. Right? He was adamant that a copy and paste would not work in new product development process practices for any company. So so lean transformation really is a journey of experimentation and learning. And it's really about building your own system and culture that that's going to work for you. However, he did explain obviously, that in his in his book that he does build on the 13 principles that define lean in development at Toyota. And those, I'm not going to walk through all 13 of those. But definitely if, if you're interested, that if you haven't read his book, that would be a great place to start. But the facilitation techniques that in the event process that I'm going to share with you are built on the learnings from Dr. liker from Jim Morgan, from Tim shipper, and many others that we have met with personally, and also through our own learning, as we've deployed this process out with many different organizations. So let me walk you through what that looks like. We always begin with an onsite assessment and interviews with key stakeholders. So this helps us to assess the true current state of each organization's product and product, process, product and process development process. And we meet with stakeholders from key functions to really understand the current state many times we ask the same questions to everyone that we meet with because when we ask the same questions, we look for patterns in the answers and that those those answers really become data for us. Right. So we're collecting data as we're having these interviews about the current state. But conversations with team and executive leaders really helped to create the goals for the event, and the future of product development at the company. So we're also helpful help, very careful to ensure that we understand what's in scope and what's out of scope for the event, right, we're gonna, we are squeezing a lot of work into a very short amount of time. So it's important that we aren't spending time spinning our wheels or, or heading down rabbit holes that are not necessary for the event. But you know, this, this obviously helps with scope creep, it allows us to stay on track and really meet the event goals. Our project charter is created and agreed upon, it's signed off by executive decision makers. And then any missing information for that's needed for the event is assigned to the team for completion prior to the first day of the the actual event. So what does the event look like? Well, this is a timeline. And you know, again, with every organization, it may look a little bit different. Obviously, this is a very high level view of what we might go through during a Lean product and process development event. But we really try to complete an event in five days, which is, which is seems a little crazy, I'm sure. But we follow with testing and adjustments that are done after the event with real product launch examples. So we might, we might, after an event, we might follow two or three actual product launches, and you know, Coach and adjust as needed with actual product launch launches after the event itself. But I want to walk through kind of what a five day event might look like, in general. Day one is usually dedicated to some training, I'm going to talk about that shortly. A current state, current state map exercise, and then day two, we get into future state all the way into day three, where we start to develop the bya. Then we're mocking and simulating, we usually simulate with a real product example. run that through the bya. And then we were updating and creating work instructions, making sure that there's a good plan for training and controls after the event itself. And then obviously, as I mentioned, there's future state evaluation that happens after the event itself. We always give the teams a daily snapshot of the agenda. We do this with every any type of kaizen event that we are we are deploying. But the agenda looks something like this, where every day the team knows exactly what we're working on. This is this Kanban approach really helps keep the team members and us you know on track and helps us gauge our day to be sure that we're not missing anything, and also allows us to see if we're falling behind or if we need to adjust accordingly. And that's reevaluated every day during the event itself. This is this is one team that that we worked with. Obviously, this is a very large team. And for some organizations that do have a very large team, we would utilize more than one facilitator would be normally two to three facilitators for a team this size, but we ask organizations to provide a cross functional team with representation across all functions of the product development process. This would include those at the corporate office, as well as any external affiliates, sometimes suppliers, even customers of the process, each event begins with an executive kickoff, you know, to really motivate the team and identify any boundaries for decision making, ensure that they have the support that they need to inspire change within the process. We do take time to review the event charter to ensure alignment around the problems to really answer why, you know, why are we in here? Why are we working on this together, and then what are the goals for the event for the for the five days, and then also coming out of the event? What are some of the goals there, we also use this time to review those in scope and out of scope, items that are necessary in order again, to just keep us on track and moving in the right direction. Our day one training normally includes an introduction to lean to process improvement, to waste reduction and introduction to Kaizen, we also always incorporate a few icebreaker activities, such as our PDCA, ball throw and or ball toss, and then the famous marshmallow challenge. If you haven't, if you're not familiar with the marshmallow challenge, this is probably my most favorite activity when it comes to Lean product and process development. It fits so perfectly with Lean product and process development. So the marshmallow challenge learnings then fit perfectly in with the team. And then again, we utilize the data that's called that was collected by Peter Skillman who actually launched or put together and, and used the marshmallow challenge across many different organizations in 2006, and after, but we use the the hands on practical experience that the team receives in order to build that into the events and activities that will happen after the after day one of their training. And then this is another really, really great activity. I'm going to kind of break this one down and show you some details of this particular activity. But we call it the four L's retrospective, we asked the team for questions. What do you like? So that's the first L is like, what do you like about the current state? What does the current state lack? So L is the lack is the second L. And then what have we learned is the third l learned and what do we longed for? So those are the four L's retrospective, we'll ask those four questions to the entire group. And you can see the post it's on the wall there. Normally, we do this as a posted activity. And as we ask the questions, the team members are bringing up post it notes with one answer per post it note and we're putting those up on the wall. After the activity is done. We will utilize the will bring the posts together and cluster them to see if we have any large datasets that really will help us to identify again, we're talking specifically about the current state. So what does the team like about the current state? What is the current state lacking? What have we learned, and then what do we longed for. And then these, the answers to this really helped to to initiate some conversations around our future state creation. So this is the beginning of our future state as we move from current to future. But we always use post it notes, as I mentioned, we summarize the information for the team and provide the data to the team to use for that future state creation. So this exercise is done in eight minutes. It's very fast. And as you can see by this chart, the team delivered this particular team delivered 103 Total post it notes for things that the current state lacks. They delivered 83 For what they longed for 58 post it notes for learnings and then 38 items that they really liked about the current state. When we broke these down into categories, that we broke them down into a kind of affinity cluster and parade of them and the team was able to then use this data in mapping the current state and the development of future state alternative which which we're going to talk about here in just a minute. So So if we look at one of these in detail, this is a what we long for. The number one answer with 14 votes was a standard process. Then this this particular team felt Like each launch team was approaching product launches in a completely different way. So the lack of standard processes was causing a lot of confusion and frustration, resulting in in product launches to be much more longer than they needed to meet customer needs. The next two items that this team long for where realistic timelines and visibility to the long term strategy. So I mean, it seems like a plausible reclass right. But the the the activity to do this and get the team on the same page was just is always just so powerful. You know, some items give greater clarity, Team autonomy, waste elimination, the identification of roles, responsibilities. Really, this exercise helps us to, you know, really level set on the on the issues, and the opportunities that the current state offers. The current state mapping exercise is always necessary and beneficial, I would always say never to skip this step. With larger product development processes, we actually separate the current state into phases. And then we split the team up to map each section. And then we pull all of that together and review it all as one team. And then once the team has completely agreed on the current state, we take time to add waste and other problems that haven't already been discussed. So as you can see, with this particular team, this was a massive undertaking a huge current state map, but well worth the time to be able to put in and level set on what that current state looks like. And that's all in day one. So now we move into day two. And day two begins with with a little bit of classroom training around future state design resources, an activity that we call the perfect day exercise. From the customer standpoint, what does a perfect product, a product development process look like. But once once we complete with that, we actually divide into groups in the sub teams. And we asked each of them to develop a high level future state map using the future state design criteria and principles that we talked about in the morning on day two. So those items that the team identifies as the stuff that they longed for. And then also, we want them to remove as much waste as possible in the current state, product and process development process. So each of those sub teams goes into a different conference room or away from each other. And they develop what they feel is the best future state design, given the learnings that they have had on day one and day two. On day three, the teams come back together, and they report out on all the different alternatives. So we might have three or four, five different alternative future state designs. Now these alternatives they discuss as a group, they vote on based on the the future state criteria, and then they develop an agreed upon single best potential solution. And these, this solution then becomes the future state of New Product Development for the company. Sometimes one of the alternatives is becomes the future state. Other times they take what they like from different parts, different alternatives, and they put that together into one future state design that they develop together as a group. And then once once they've agreed upon that, you know, will move that future state map into Visio, or some type of software that can be used to act to assess the approach going forward. This potential, the potential solutions that will practice and adjust after the event, right, the these are put down and obviously some type of structured format. And then again, during the next two days, sub teams will actually create the breakdown and detailed work instructions inside of each of the agreed upon development phases. training standards are also created and then rolled out rolled out as possible. Finally, visual management is developed to help track and manage product launches. So the buyer space becomes a great way to incorporate conversations and updates for leadership. So this is also part of the event all you know, and this is normally happening, end of day three, beginning of day four. So again, I don't know how many of you have heard of the terminal by I'm sure most of you have, but it means big room. The approach works great for new product development launch teams. It also gives great opportunity for leadership to easily easily visualize the status of a launch and then also gives you know some questions when we give them some questions when we're developing an Obeah Um, so some of the things that we might ask them are, you know, can you see the work the flow of work from left to right across the wall? Can we see what one unit of work looks like? Can we see and immediately understand the status of a unit of work, right. And a unit of work could be an actual product launch, it could be a breakdown in a piece within a product launch. It just depends on how the team defines what a unit of work is. But another question might be, has the work been properly refined? Before it comes into the the bio? You know, is it assigned to somebody? What's the time estimation? That type of thing. So we always include some kind of a color key or a legend. We post that on the wall, we have a huddle agenda, huddle, schedule, huddle roles and responsibilities. The team understands what their true north KPIs are. So if we want to ask them, how do we define success for a product launch, they should be able to tell us what what what that means. How do we define success for a product launch, we always ensure there's an escalation plan. So if a product launch is falling behind, based on what we've defined for success, or you know, time estimation, or whatever that may be, then we have an escalation plan for how to get that that product launch back on track. Executive Leadership, managers should be in regular attendance of these meetings to help the team remove roadblocks receive feedback, even receive tactics, you know, propositions from the team, it's really a two way conversation that happens there. So, you know, a via the via meeting should really be cross functional and attendance, just like the just like the event itself. You know, I've seen some teams that have utilized technology for teams that are not in the same physical space. But obviously, you know, I love in person meetings, like the one you see here, you know, these, this fosters direct communication at all levels of the organization, it helps us to see the visual schedule, again, just a visual representation of whether we're ahead or behind a visual representation of the entire product development process, we're really the the goal is to catch issues as early as possible, identify, communicate, you know, assign them to the right person. And then some of you may be familiar with agile, but some of the Agile principles, you know, usually tie into our bias as well, you know, we we really, we take things that are that are considered ungroomed black backlog, so any new product, new product that are going to enter into the system, you know, needs to be discussed before they actually enter into the visual system, so that, then the middle wall, you know, changes continuously, but it's useful to review at least once per, you know, sprint or as part of a retrospective, and then, you know, the right wall changes continuously, and should be reviewed at least once per day or minimum, weekly. Again, with that product launch team meeting at that board and having constant conversations about what's happening around that particular product launch. You know, they have to agree on timeframe, huddle agenda, you know, again, some of this can be adjusted over time, but it has to be posted, along with any types of rules. Catch ball was is another thing that that we always talk to teams about during the development of the Avaya, but we want to make sure that, that we're creating and maintaining open feedback loops across all levels of the organization. By establishing really that the two way communication, you know, for information sharing, and leaders are really expected to show up at the FBI and have real conversations with the team about their product launches. So this is an opportunity for leadership to communicate any changes, recognize staff members, you know, also for leadership to listen, and respond to the team about any roadblocks or request for help. And the last thing I want to mention about this is, you know, just making sure that managers understand their role, you know, their role is to really support the workers. So show humility. They're not there to tell everybody what to do, but they're really asking genuine questions. What are your struggles? What can I do to help? Is there anything that that I can escalate, they're listening actively, it's really not a time to show control and tell the team but really a time to listen, get alignment and understanding of common goals. So, you know, attending these meetings are, are necessary and also seeking to understand and really spending time to actually respond to the things that are that are said. So here are some of the questions that you know might happen might come from leaders when they're attending a launch teams Oh, by a meeting, you know, what do you think? Thank you What do you need from me? Apologizing? Value your contribution, right? This is the humble leader, leading as a humble leader. And then, after the event, it's imperative that the team follows real product launches. You know, I mentioned this, but this is after the event itself, we need to understand what are the roadblocks, the hang ups, the problems, or whatever, to ensure good flow throughout, right, it's a really a larger PDCA cycle, right. So we need to be willing to learn and adjust as we are following through with the the results of the event on an on a real product launch. Now, this was actually a necessary point that came from Dr. liker, he said that, you know, one five day event is not going to result in a six in successful Lean product launches, there has to be continued follow up with real launches, following the process closely and seeking out learning points. That, again, the team has to be flexible, to adjust and act as the new product process is really checked throughout. It's a remember, it's a journey of experimentation, it's an opportunity to develop the process over time, following those consistent, you know, PDCA cycles throughout. So that is kind of an overview of how the event works, and how we lead it, you know, just coming kind of bringing everything back around to the notes that I threw up at the beginning. You know, Lean product development is addressing reduction of long development cycle times, it's reducing high cost of development, production costs, right, those redevelopment cycles. Basically, we're looking to maximize the product value while minimizing waste in the process. And again, those those nine recommendations from Tim that I covered, knowledge sharing was key, spend more time learning upfront, don't fear failure, develop goals upfront, define the abilities, don't move ahead without completing work upfront, allow groups to work in parallel, map out and identify key key key stakeholders and key decisions, and then focus on the product upfront. I won't, again, I'm not going to go through the 13 principles that define Lean leadership that Dr. liker laid out. But I think there's a couple that are really key. The first one, establishing customer defined value to separate value add from waist, making sure that we have a some type of a chief engineer to to oversee the entire system is something that we always push for because the value of having one person overseeing the entire process is is just so imperative. But organizing, you know, to balance functional expertise and cross functional integration, there's just so many good points that come out of of those 13 points. And then, you know, just kind of going back to the event itself, on the pre work. So onsite assessment, interviews, data collection, Problem identification, goal creation, Project Charter, those are all important pieces of the pre work. Some important points you need to understand about the event itself. The pre work is key, ensuring executive kickoff, use activities and icebreakers to keep people engaged use visual management, the Baia which is the means the big room right and then daily management, keeping it visual consistent, ensuring that leaders are engaged to support ask questions, remove roadblocks. Those are basically the the main key points of how we facilitate and run a Lean product process development event. Thanks so much for tuning in to this episode of the lean solutions podcast. If you haven't done so already, please be sure to subscribe. This way you'll get updates as new episodes become available. If you feel so inclined. Please give us a review. Thank you so much.