Jim Luckman has had the unique experience of leading three separate lean transformations, as a Plant Manager, as a Director of a Research and Development Center, and as a CEO of a small start-up company. During the podcast, we discussed Value 
Stream Mapping and delved into Value Stream Concepts as they applied to Lean and Agile Software Development. I found it interesting his take on the “Newer” Lean concepts and how they are viewed by a more traditional practitioner.
Jim is the Past President and CEO of iPower Technologies, a company serving the distributed generation market of electrical power. Luckman has worked in the auto industry for 34 years working at Delphi Automotive (formerly part of General Motors). Jim current efforts include leadership coaching, application of lean in R&D and application of lean to software development. He currently coaches companies interested in company-wide lean transformation. Jim is a partner in Lean Transformations Group, LLC.
Download PDF Transcript of Podcast
Related Podcast: Applying Value Stream Concepts
Transcription of the Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Joe Dager: Thanks everyone for joining us. This is Joe Dager, the host of the Business901 Podcast. Participating in the program today is Jim Luckman. Jim is a partner in Lean Transformations Group and an expert in Value Stream Mapping. Jim, would you explain what you do at Lean Transformations Group?
Jim Luckman: Lean Transformations Group is a group of very seasoned consultants. Some have come directly from experience inside Toyota, and some have grown up in the US trying to learn and understand how to create problem solving cultures inside companies. So, what we all do is help companies begin to transform to engage all of their people in solving problems at all levels inside their companies.
Joe: You have a very diverse background; I have seen you have been a plant manager,director of research, a CEO of a small startup company. That’s a pretty impressive resume’ that I look at it. Did you apply Lean and all these areas?
Jim: I think that one of the things I learned is that when it comes to getting an organization focused and taking personal responsibility for solving problems in their area, it really doesn’t matter if it’s manufacturing or a R&D center or even a small startup company that I had. It’s about trying to get the reputation about the set of problems you have from a business point of view and getting people aligned to helping solve those problems.
Joe: Interesting that you say that, when someone first thinks of Lean, many times they think of manufacturing. We were discussing before the podcast of how Lean really came to America was through the automotive industry. You do the Value Stream Mapping class for Lean Enterprise on office and service. Are there a lot of changes that you do in applying Lean to office and service?
Jim: The Value Stream Mapping that came, generally speaking, into United States, the very first version of that was depicted in “Learning to See,” a Value Stream Mapping workbook. It was primarily oriented toward manufacturing. We got a chance to take Value Stream Mapping several years ago, about seven or eight years ago, into the non-manufacturing areas and develop the way you do Value Stream Mapping for non-manufacturing areas.
What we found is that instead of the material flow that you look at which takes place in manufacturing. In the office and service area, it is information that needs to flow and as a result of that there are a few unique changes to the way you look at Value Stream Mapping for office and services. And the product that we did develop that is related to that is called mapping to see which is offered through LEI.
Joe: You are looking at the information flow and how that flows instead of a part going down the assembly line. You are looking at just the basic information and how that flows from the beginning or a customer entry point to actually when the customer sees it.
Jim: That’s exactly right. In fact, almost all of the work inside the non-manufacturing area is exactly that: it’s information of some sort that needs to flow from one point to another. I think a real good example of that would be accounts payable. For example, there is a request of some sort to pay something, and it goes through a whole bunch of steps. Usually, in the accounting area and it ultimately ends up getting sent back to the customer, in this case, as a check. The real deal is all information that is flowing through that whole process and the final delivery is a check.
Joe: To do a value stream map, do you have to define the starting and beginning point?
Jim: Yes, it is always a good idea with Value Stream Mapping to put the two boundaries on it. It’s the output, in other words, the end of the value stream ? what is it you are looking for as what’s being delivered. The input is where you want to start that Value Stream Mapping analysis. Again, quite often in administrative processes is the customer is the supplier of the initial input. Take, for example, if you were trying to value stream map the tax service, the input to the value stream is a bunch of documents that the client would have to give to the tax person so that the tax person could create the actual tax forms. And then the tax forms would go back to the client asking for a signature so that it would go to the IRS.
So, yes, you do need to specifically define the starting point and the ending point of the value stream and stay within those boundaries as you begin to map and understand the problems of the information flow inside that value stream.
Joe: When you go into a company, is the value stream map one of the first thing that you do or do you introduce the value stream map as part of the process you decide to work on?
Jim: When we do go into a company, what we prefer to do is to start with some level of management, preferably senior level of management, and say what business problem do you have. Is there a business problem that you would like to solve? That would help to sort out where we would devote some effort to look at value streams inside that problem area so we can begin to get the people in the organization focused on that specific business problem area. We would then scope the value stream in that area, the starting point, the ending point, what are the problems? Who are the people involved in it? And create the three day workshop so that we could engage those people who are inside that value stream to understand their current state, design a future state, and then finally end up with a plan to be executed over the next three months.
Joe: You really look at let’s say chunking it off. Go there, find a specific problem and start working on that somewhat early in the process?
Jim: Yes, we would figure that out with the senior leaders of the company. Again, the business area that needs to have improvement and we would define the starting and the ending point for that so we would stay within those boundaries as we do the value stream improvement project for them.
Joe: What kind of surprises do you get some time when you try to do a current value stream map?
Jim: I think the biggest surprise to me is that it doesn’t matter what industry you do this in, whether it’s aerospace or health care or high tech or any other industry or finance. It’s the value streams that, generally speaking, all evolve over time to way too much complexity where the people don’t understand the entire value stream. And that there’s always a lot of rework and delay and waste inside the value stream causing huge delays in terms of the lead time, that is, the time from start to finish. It’s almost the same everywhere you go, independent of industry. And that would be my biggest surprise working with this over the years.
Joe: I always kind of wonder that when I give a piece of paper to someone and they say, “Expect the response in two to three weeks.” It’s like, what do you mean? It’s a two minute job.”
Jim: Absolutely. Actually, there’s some metrics that really highlight that in this Value Stream Mapping approach. There are three metrics that we find that are very common and should be used in analyzing the performance of value streams. The lead time is what you described there, the time from the request to finally getting the answer. That’s the total lead time. The process time is the actual touch time that it takes operators or people to do that job. In other words, it’s when someone inside that organization is actually working on that request, and that’s the process time.
One of the things we find, again, in almost all value streams is the process time. It’s usually a very, very small percentage of the total lead time, and you can see the waste just by looking at those two numbers.
And then, the third metric is what we call percent complete and accurate, and it’s a way of measuring the quality of hand?offs inside the value stream. So, you get a sense of how much rework is required because of the poor quality of hand?offs.
Joe: That kind of reminds me of Kanban. The Personal Kanban where you have three columns to do, doing and done. Doing doesn’t really take that long, but it really is how complete something is that you’re getting if you have all the information, and then when you pass it on that you’re passing all the information needed in the next step.
Jim: That’s correct. In fact, those hand-offs are usually a very big problem because if you’re not paying attention to the quality of the hand?offs, then the information will be worked on. And all of that work will be of waste, and it has to be redone. So, paying attention to the quality of the hand?off with this percent complete accurate is a real key metric that needs to be looked at in creating a future state value stream.
Joe: You start with a current state map then you build the future state. Is that future state a pie in the sky? It’s not necessarily going to be right. Is that true or are you just dealing with things that you know that’s going to happen?
Jim: Well, you’re exactly right on the fact that the future state is the hypothesis of what you think you can accomplish. And normally that does not necessarily mean it can’t be accomplished. So, there really are three days of getting this team involved in creating a plan. Day one is the creation of a current state along with all of the problems that can be exposed, what’s going on today. The second day is all about creating a future state, getting the same people to say, “How can we design something to eliminate all of this waste and this rework?”
And then, the third day is creating a very realistic plan to be executed over the next three months so that we can move from our current state in the direction of the future state. And we can find out what will work and won’t work as a result of this three month execution plan.
Joe: I like that you’ve broken it up that way because I see so many different programs, and I’ll use Value Stream Mapping as an example; someone will do the current state and they’ll do the future state. Or in a book, they’ll write 200 pages on current state and future state and then the last chapter they talk about achieving the future state. You’ve given that equal footing, which I like because that’s the hard part.
Jim: Absolutely. And, I mentioned a three day workshop where you do current state and future state and the plan. The interesting part to me is that at that point when you walk out of the three day workshop, you really haven’t experimented with moving your organization in the direction of the future state yet. All you have is a plan. Now comes the hard work at trying to experiment, find out what will and won’t work and make corrective actions along the way so that you can achieve the future state.
That’s where the cycle of learning takes place where you go out and try something and it either works or it doesn’t. If it’s not working, you’ve got to have a counter measure put in place to keep you on track in trying to achieve that future state.
Joe: It always looks good on paper. You design that future state and as you say you go out and making the adjustments, a lot of times you’ve had people from different parts of the company maybe help design the map and then someone else has to implement it. Does someone have to take ownership or how do you get that accomplished?
Jim: In the scoping session prior to the three day workshop, we’re very clear about whom the value stream owner is and who the champion is and who, if they need it, the project leader for the specific project would be. So, the owner of making all of this work is the value stream owner. It’s typically someone in a management position that has the job of making sure that this value stream will get improved. Because of the way organizations are fragmented, it might be the owner or the functional leader of one of the functions that are supporting this value stream.
So, a good deal of the difficulty comes, as you mentioned, from people going back to their functional leader and the functional leader says, well, you know, that’s great for that, but it doesn’t really fix my function.
So, it does raise a problem sometimes if, in fact, you haven’t done a good job of scoping and getting all of the functional leaders to understand what you’re trying to do as you cut across those functions to fix value streams.
Joe: A value stream champion really has to drive that project and has to get other departments to follow him, right?
Jim: That’s correct. We do need to have a good group of leaders working together who should all be supporting the value stream that cuts through all of their functions.
Joe: Now, is it visible what’s going on within the plan?
Jim: We also try to encourage companies to create a visual board that not only shows the problem that you’re trying to solve and the current state and the future state and the plan, but a way of keeping everybody on track with the execution of that plan. The best way to do that is the old war room concept that you have all of the plans up on the wall.
If you can use that to get everyone on board in terms of what they’re trying to accomplish and meet there at least every month along with the leaders to make sure that the plan is being executed properly, and appropriate counter measures are put in place in order to keep it on track. So, visual planning’s a big piece of this, and visual management.
Joe: I liken the concept to the Agile and the Scrum people use of the Daily Scrum method, and they have that board there. Then, for the software guys to get something done that day, they had the gatekeeper take care of people coming in to protect them. That’s not all that bad of an idea.
Jim: The Agile methodology with the sprints and the visual management that’s attached to that is very appropriate for doing this type of work. It is a visual management system that allows everybody to see the whole picture and understand what each person is doing as they’re executing inside an agile project. It’s actually the same kind of methodology that we are promoting in terms of these Value Stream Mapping projects.
Joe: We talked about this yesterday is that Agile has grown out of Lean. Or the Lean software development has taken it and called it something of their own, which is Agile, and then of course Scrum, XP, and Kanban has grown out of that. But, there are a lot of similarities there. What’s the difference do you think between the Lean software development crowd and the more traditional Lean practices and how that has evolved?
Jim: Let me back up with the Value Stream Mapping. I mentioned two Value Stream Mapping approaches. One was oriented toward material flow in manufacturing, and the second one was information flow in the offices. Now, in both of those cases, generally speaking, they are transactional processes. In other words, you do something, and then you hand it off, and you do something else to either that material flow or that information. We’re calling those “transactional value streams.”
There’s another type of value stream that I call a “creative heuristic value stream.” This is one where you have to do something and get an answer to something before you can go on to that next step. So, you’re seeking answers to questions, and that is what software development is all about. It’s what I’m calling a “knowledge growth value stream.”
So, instead of just passing information from one step to the next, you have to do something to find an answer to the question. Then that gives you guidance on what the next step would be.
So, software development fits into the category of a knowledge-based value stream, and that requires having cycles of learning. I call them “fast cycles of learning” which is the way to quickly development software on a timeline that is a whole lot faster than normal. That’s where it all comes together is the principle of Agile is basically one of exactly the same thing I described, which is a knowledge-based value stream.
Joe: You’ve worked in that area then with agile people. Do you switch into their methodology a little bit? Or do you stay with your nomenclature methodology when you’re doing that?
Jim: I actually just got through doing a Value Stream Mapping workshop with a client in software development, and they had quite a few years of Agile built into their system. What we ended up doing was allowing them to value stream map their existing condition, which included all the good and bad work going on inside Agile, and get them to see their value streams at a little bit higher level than they have been able to see it inside the Agile methodology.
So, interestingly, there were about three or four things that popped up as common problems that we’ve seen in other areas, and very specifically one was not doing an adequate job of understanding the customers’ needs or problems ? was one problem that popped up.
Another one was that they were generally doing their sprints, trying to manage tasks rather than manage the knowledge growth. And the third area that popped up was the connection to all of the support areas was rather poor, had long delays, and sometimes poor handoffs.
So, we exposed some problems by taking a look at it from a value stream perspective even though they’ve had four or five or six years’ worth of Agile or Scrum integrated into their system.
Joe: It sounds like when they got involved in the Agile, as much as that’s supposed to be about customer needs or receptive, they kind of became reclusive within their team.
Jim: That’s correct, and I would say that there is another element of taking this Lean approach and Value Stream Mapping approach that tends to not be seen in the agile approach. It’s one of getting the people who are doing the work engaged in being able to see their work and make continuous improvement to it. So, what I’m suggesting is that even though inside Agile there are methodologies for trying to do continuous improvement, my observation is that it appears in some companies to be too prescriptive. It doesn’t really open up creativity amongst the players to the extent you’d like so that they can continuously evaluate their performance of the value stream and make improvements to it.
Joe: One of the difficulties that any of us have is getting the feedback from the customers. The customer’s got a life. He is trying to make money and survive. Have you seen a way to do that?
Jim: Yes, I have seen a way to do that. This actually dates back several years ago on a SAP application. The standard of software development at that time, for me, what I saw in the industry, was to have a lot of system engineers go out, talk to managers inside a plant on what they needed from a SAP perspective, put together huge documents of these requirements, and spend a lot of time and money at it. What we were able to do in this one company was create real quick prototypes with the actual users of SAP in the plant with coders, bring them together on a weekly basis, create a weekly plan with daily standup meetings, and just look at all of the different alternatives of how they might be able to create screens that would be appropriate for the operators and help them do their work.
What we found is that, through that exercise, they were able to take tremendous lead time out of the value stream improvement and end up with a much more robust definition of customer needs.
Joe: Well, I think what you’re saying there is just those short iterations that you go so far, yeah, nay, go so far yeah, nay. As you’re doing that you’re just keeping the good stuff?
Jim: Exactly. That’s exactly what we’re trying to do. It does take an integration of the client or the customer along with the software developers to look at those alternatives and quickly reject bad ideas and keep the good ones. Again, that’s that futuristic process. It’s those cycles of learning inside software development that applies to the upfront piece, which is understanding the customer’s needs and problems.
Joe: My thoughts still goes back, what’s in it for the customer?
Jim: Well, the experience I have is that they not only are able to help define their requirements that are up front, but they will get a higher quality product at the end of the process because they helped to a larger extent define their needs more accurately up front. But, the other piece is that, in the one case that I’m talking about here; the development went from 20 months to six months. What was in it for the customer was the ability to use the software a whole lot sooner than normal.
Joe: If he’s going to save money and has a problem that he’s trying to solve, speeds not a bad thing to have on your side.
Jim: It’s once again that lead time reduction is real value.
Joe: When you’re looking at doing a process like that it’s pretty important to have what we say is a need out there. I always describe it as one thing you have to have, a need to have a product. You also have to have someone willing to spend money to correct that need. It sounds silly, but a lot of people design a system based on their thoughts. They think they improve something, but it may not be what the customer needs.
Jim: Most of the improvement that you get from these value stream projects improvement projects, particularly in either product development or software development is that quality of launch is often a requirement that is the business problem to solve. Quite often, it’s just how long it takes to actually to get to that launch, which is that lead time improvement. So, we actually see improvements in both the quality of the launch and reduction of lead time improvement, both of which serve the customer with a lot higher value of software than what they had before.
Joe: I’m going to pull back to Value Stream Mapping to achieve the future state. Achieving future state somewhat like a launch?
Jim: It is exactly the same. The methodology of putting execution into the cycles of learning for Value Stream Mapping is exactly what we are talking about for software development. It’s cycles of learning and us making correction and launching better and faster at the end.
Joe: The other thing that I noticed about Lean that people like to make it something of their own. It’s like we’ve went through all these different phases of continuous improvement. A black belt may be very similar to a value stream champion. You have a project owner in both of them. You have a scrum master. Am I saying that correctly, TQM, MRP. We go through all these different tools we’re using. Now we have revolved into Agile, is that continuous improvement? Is it just important that we are doing it?
Jim: The best explanation that I have for that is that we tend to think in terms of applying tools, and we name them different things. And as a result of that, sometimes we throw out the old tools in the interest of the new tools and even programs. If you want to peel this back, what Lean really is about, it’s about the complete creation of a problem solving and fast learning culture. And what that implies is that it really is all about engaging everyone in the organization in effective problem solving and learning. If you take a look at the tool set that can be given to you, you can integrate that into the process of improving the capability of the organization to solve problems and learn. And it becomes a self-correcting and continuous improvement process.
Joe: I think that’s very well said Jim. Lean was always so much associated with waste, and certainly it is used to improve something and get rid of the waste. I never looked at the primary function of it was getting rid of the waste that was a bi-product of Lean. It wasn’t the main thing. I think; problem solving and learning as being the main thrust of Lean.
Jim: One other point I want to make is that interestingly, if you go back in history and you think about how Lean came into the United States, it actually somehow got morphed into using the tools that Toyota had developed for themselves in order to solve problems and apply those tools to your business or your organization. What we learned is that when you do that, you actually might be creating more waste as a result of that rather than eliminating it because you’re just putting tools on top of tools.
So Toyota, over many years, developed a set of tools to figure out how to fix their problems. Just applying those tools is not the right way to do Lean inside our companies.
We need to step back and say how do we really create a complete organization of problem solvers to solve our problems? And then, use the appropriate tools to help us do that.
Joe: Is there something you’d like to add to this conversation that maybe I didn’t ask that you’d like to tell listeners about either the workshop or the organization or Lean itself?
Jim: Yeah, I think there is one piece that we didn’t cover a lot of and that is the model of leadership or management. Let me start with management. There is an element of managers and leaders needing to question everything they’ve learned over the years about what are management and what is leadership in support of creating a culture of problem solvers and learners. So, many of the management principles that we have in place right now actually detract from creating and opening space for the people in the organization to solve problems.
And that’s another part that has to be addressed when you believe in creating Lean interventions in companies is to take a good hard look at the management system, what needs to change, how do you create experiments around that and move you in the direction of creating a problem solving and fast learning culture?
Joe: I would like to finish up by saying you very much, Jim. I appreciate it. If you’d like to find out more about Jim or the Lean Transformations Group, they can be found at Lean-transform.com. You can listen to this podcast on the Business901 Podcast site, or it is available in the Business901 iTunes store. So thank you again, Jim.
Jim: Thank you.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook