What Van Halen can teach us about Visual Management

Visual Management is a critical component to Lean Product Development. When I visit organizations I often see teams standing in front of a display board discussing their projects the same way they would in a meeting room. It’s just that they are standing in front of a board. They completely miss the fundamental principle of Visual Management.

Research has identified 4 characteristics ever present in exceptional organizations. These 4 characteristics embody the very essence of Visual Management.

Exceptional organizations …
1. Create systems that show problems.
2. Quickly solve problems and improve the system.
3. Create and share learning.
4. Leadership takes responsibility for the system and developing the people.

In manufacturing, these principles are relatively easy to implement. When there are physical items moving along an assembly line, there are many ways to make issues visible. However, as the work becomes less tangible, like in product development, it becomes increasingly more difficult to highlight abnormalities and effectively address them.

Which brings us back to what Van Halen teaches us about Visual Management. The 1970’s witnessed the ascent of Van Halen’s stardom. As their popularity grew, so did their ability to make demands for their concerts. Documenting these demands in contracts, they specifically spelled out their promotors’ obligations. Easily lost among the finer points of Van Halen’s contracts was the seemingly insignificant demand for M&M candies back stage with the most unusual stipulation of no brown M&Ms. According to the contract, if any brown M&Ms were present, Van Halen could cancel the concert with the promotor bearing the full responsible of all costs. This meant that if just one brown M&M was found in the candy bowl, it could cost the organizer millions. At first glance this seems to be the pinnacle of Rockstar arrogance and excess. But understanding the meaning behind the demand highlights the brilliance and brings to light a completely different perspective of this demand.

Van Halen’s lead singer, David Lee Roth explains that the clause for ‘no brown M&Ms’ was simply their way of knowing whether the organizer had actually read the entire contract. These contracts had many critical stipulations which were nearly impossible to verify prior to a concert. Demanding something as trivial as having someone pick all of the brown M&Ms out of a candy dish was their signal that the promotor had read the entire contract giving the band confidence the more important aspects had been addressed.

Think about what the ‘Brown M&Ms’ signal – Where are the Brown M&Ms in your development system? To evaluate your Visual Management system, ask yourself some basic questions:
• Does my system clearly highlight abnormalities?
• Are there clearly defined ‘Help Chains’ in place to effectively resolve problems to maintain development cadence?
• Do problems lead to improving the system?
• Do we learn, and do we share our learning broadly, so lessons do not need to be learned again?
• Is my leadership engaged? Do they take responsibility for the system and development of people?

If you are interested to explore more Lean Product Development principles, down load ‘Lean Product Development in a Nutshell’ here: https://www.developlean.com/lean-product-development-in-a-nutshell/

… and in conclusion – Van Halen

Is proactive learning necessary?

It is that time of year, when summer has drawn to a close, the leaves transition to their display of color, and school has started anew. A lot of parents breathe a sigh of relief as their kids return to their books and learning. Summer holidays sadly behind us, we return to our routine schedule; the countdown to Thanksgiving has begun.

I find as the days grow shorter and nights turn colder, I still have that inexplicable urge to shop for school supplies. Usually I end up with at least some new notebooks and pens – which my wife quickly points out I really don’t need. She is right, but I just love the reinvigoration that a new school year brings and the challenge of learning something new. Last year I took a linear algebra and differential equations class – just for the fun of being in that environment and the challenge of learning.

Over the summer I was thrilled to learn that the book, “The Lean Machine” was awarded the Shingo publication award. It was written to share what we learned at Harley-Davidson about lean product development. I am very grateful for the recognition and extremely appreciative of the wonderful people at Harley-Davidson who made it all possible.

Recently Dr. Durward Sobek and I took on finishing writing and publishing a manuscript that Dr. Allen Ward was working on when he passed away. The manuscript deals with visible knowledge and learning in the workplace. Productivity Press is on board to publish it, so the deadline that seemed comfortably far away when we started is now upon us.

Working on this project with Durward reinforced just how much fun and invigorating learning is and how scarce ‘proactive’ learning seems to be in product development.

So is proactive learning really necessary?

What are you learning proactively on your projects?

How do you stimulate those around you to learn proactively?

I’d be interested to know – Dantar@TheLeanMachine.org

Interested in information on the Shingo award? The link is here: The Lean Machine

Product Development is like walking on water – It’s a lot easier when it’s frozen.

I remember being a new engineer bent on setting the world on fire. I was less than 5 years into my career, excited to be working at General Motors on the Chevrolet Corvette. I recall seeing a cartoon pinned up by the desk of one of the ‘experienced’ engineers. The cartoon was of a person walking on a frozen lake. Under the cartoon was a caption that read, “Engineering is like walking on water – it’s a lot easier when it’s frozen”. I remember thinking, ‘That’s right! Why can’t we just get clear product development specifications that are frozen before we start and don’t change, so we can do our work?”

I spent most of my career with that mindset, “Why can’t those guys just decide what they want and freeze the specs so we can design?” (By the way I’ve found it’s always ‘those guys’) As I learned and managed through stage-gate processes, I put a lot of emphasis on clear requirements and freezing specifications early in a project. It was a lot of work and specifications always changed during the project. I consoled myself by justifying the work of freezing specifications with the belief that if we didn’t invest that time, it would only be that much worse.

It wasn’t until I started working with Dr. Allen Ward and he introduced me to Lean Product Development that I realized my approach was nothing short of absurd. How could I possible freeze specifications at the beginning of a project when I knew the absolute least about a project? Development is all about closing the gap between what you know when you start a project to what you need to know to launch a project. Freezing specifications and picking a solution early (point-based) results in an organization frantically forcing a suboptimal solution in an attempt to make a launch date.

The whole basis of Lean, or Set-Based product development centers on narrowing the specifications as the organization learns more about the capabilities through the course of product development. As the design progresses, specifications and respective sets of solutions are gradually narrowed based on the knowledge gained. Counterintuitive to everything I had been taught, critical design decisions are deliberately delayed until the last possible moment to ensure that customer expectations are fully understood and the final design converges on an optimal solution that meets the requirements of all functions (design, manufacturing, etc.).

Set-Based (Lean) product development provides for a structured approach to narrow solutions sets in a way that brings specifications and technical capabilities together to optimize the design and the project. A fundamental byproduct (or perhaps the driver) is that the organization works to learn and capture knowledge in such a way that the learning is reusable on subsequent projects making each project more efficient and effective than the previous. I’ve seen 2 and even 5-fold improvement in organizations that switch, and the work is more rewarding as well.

Isn’t that why we all got into product development in the first place – we like learning, discovery, and introducing cool new products and services?

Death to Stage-Gate

Allen marched into my office with authority, slammed his fist down on my desk with a loud bang and proclaimed, “Damn it Dantar! You’ve got to abolish stage-gate! Its evil – Kill it or I’m not working with you.”

Dr. Allen Ward was brilliant, a bit eccentric at times, but that was part of his charm and effectiveness. I had convinced Allen to work with us to improve product development at Harley-Davidson. Now just a few meetings in, he was demanding I abolish the backbone of our development system. The entire organization was focused on stages and exits? I had grown up with Stage-Gate systems. It was comfortable. It’s all I knew. Abolish it?

It was after this conversation that I really began studying my metrics and with Allen’s coaching started looking at numbers I had always monitored in a different way. When I looked at my data differently I came to realize that over the past 5-years there had been absolutely no correlation between stage-gate exits and successful projects. All my effort had been focused on forcing the organization to work harder to get their exits on time. What a waste! But, that’s what I had been taught, and all I knew.

Before the obituary for stage-gate is prematurely written, let me say that stage-gate has value, just not as a development process. Stages and Gates can be effective for fiscal oversight, but makes for a very poor development framework. But replace it with what?

Shifting to a Set-Based, Lean development framework driven through Integration Events drastically improved our throughput and predictability. It’s not an easy switch, and I found much of what Allen taught me to be counterintuitive. But the efficiency and effectiveness of a set-based, Lean development framework is well worth the journey.

Why do organizations persist in using an ineffective development framework? Is it all they know?

If you are interested in a framework for the systematic improvement of product development through organizational learning, there is information in this article: https://www.linkedin.com/pulse/framework-systematic-improvement-product-development-dantar-oosterwal

If you’d like to learn more about the transformation to Lean Product Development at Harley-Davidson, there is information here:
https://theleanmachine.org

If you would like to learn more about Lean Product Development, you may be interested in an on-line seminar with information here: http://leanfrontiersdirect.com/lean-product-development-lean-frontiers-direct/

Related Article: Why do organizations expect the result Lean Product Development delivers but are unwilling to do the work?
https://www.linkedin.com/pulse/reflecting-dr-allen-ward-why-do-organizations-expect-oosterwal?published=t

A Framework for the Systematic Improvement of Product Development.

I tell my friends in manufacturing they have it easy. Manufacturing is easy to improve because you can physically see the work. You can follow the flow of material from incoming receiving to shipping. You can watch a part come into a machine or into an assembly station and see the physical transformation of the part. You can walk into a factory and know immediately if ‘the line is down’, count the rate it’s running (Takt time), and you can see the problems. That is not the case in product development. I can’t stand at my office door or peak over my cubical wall and see if ‘product development is down’. Most organizations don’t even think about their product development rate (cadence). I can’t see the flow of work and I can’t see the problems. I can see the results of the work, the output of my product development system, and I experience the consequences from the problems caused by a system I can’t see every day. So how do I improve a system I can’t see?

History has shown the only way to improve is by learning and doing. You can’t improve if all you do is learn and never apply what you learn. You won’t improve if you work hard but never learn. In order to improve you must ‘Act and Reflect’.

So let’s put this notion of Action and Reflection in the context of a product development system. The diagram at the top depicts a framework for learning and action to improve a system you cannot see. (The Learning / Action Matrix™)

Along the vertical axis are stages increasing in depth of reasoning. Progressing up the axis, each stage increases in leverage but reduces in tangibility. Your greatest leverage for change is in your vision because it has the broadest reach, yet vision is the least tangible. The least leverage is in individual events that occur in the product development process, although they are the most tangible. Unfortunately most organizations spend their efforts on tangible, low leverage events in fits of ‘firefighting’ just to get product out the door and never progress up the axis where the real leverage for improvement exists.

How do you instill a vision and improve product development?

The Learning / Action Matrix™ above identifies the four steps necessary. Learning begins in the first step by observing the events and patterns that occur and testing your observations against your vision. How do the actual events and patterns you observe compare to the vision you have? What are the gaps? Gain clear alignment and document the gaps against your vision, then move on to step two.

The hard work of leadership and improvement begins in step two by assessing the systemic structures of your processes that caused the events and patterns you observe. For example, were resources shifted from later projects to help resolve problems with projects closer to production creating more issues on the projects they were pulled from? Why? What caused the need? A strong leadership team will challenge themselves in assessing their individual mental models of what occurred and why. It is critical this happen without pointing fingers or blame. Build a collective mental model of your development system and test its behavior against your vision.

Step three entails identifying the changes in behavior that the leadership will undertake based on alignment on mental models to support the shared vision. As you assess the connection between behaviors and results, develop the changes to the system and actions you will take. Use the scientific method to improve your next learning cycle by documenting the improvements you believe your changes will deliver.

Finally, step four – take action! Go implement what you identified. Change behaviors based on the structured, deliberate rationale you agreed. Hold yourselves accountable but recognize you have not achieved perfection; so get ready to do it again.

Setting aside one day per month or per quarter for your team to reflect is a good way to start. If you want to kick-start the process, borrow liberally from proven Lean Product Development methods as part of step 3. Do not implement blindly. (Blind followership does not allow for learning) Challenge the changes against your mental models of how your product development works. That’s how you learn. There’s just no way to circumvent these cycles if you want to learn and improve.

Related Article: Why do organizations expect the result Lean Product Development delivers but are unwilling to do the work?
https://www.linkedin.com/pulse/reflecting-dr-allen-ward-why-do-organizations-expect-oosterwal?published=t

If you’d like to learn more about the Learning / Action matrix™ and its application, the book, The Lean Machine, provides insight through its application at Harley-Davidson with information here:

Businessx Front Page

If you would like to learn more about Lean Product Development, you may be interested in an on-line seminar with information here: http://leanfrontiersdirect.com/lean-product-development-lean-frontiers-direct/

Reflecting on Dr. Allen Ward – Why do organizations expect the results Lean Product Development delivers but are unwilling to do the work?

The first time I spoke with Allen, it was early 2000’s. I had called Allen to ask if he would help us improve product development at Harley-Davidson. I was the Director of Product Development at the time. My quest to implement Lean Product Development had actually started with a call to Jim Womack at LEI who suggested that I talk to Allen – That is, after he more than emphatic told me, “Do not try to bring lean manufacturing upstream to product development! “.

I tracked Allen down and explained our predicament. Although we were profitable, and product development was churning out really cool products, life was anything but rosy below the surface. At one time the wait lists for our products had been as much as two years. So as any good business, we worked hard at, and improved our ability to get motorcycles out of our factories and into the hands of our waiting customers. So what’s wrong with that?

The backlog of customers waiting on orders had mostly evaporated as we improved our ability to deliver. At the going rate, it would not be long and we would have a glut of bikes on our hands. Anyone who has ever played the ‘beer game’ (the system dynamics one, not the drinking one) knows this is not a good situation. In order to make our growth objectives we had to introduce a lot more new products to drive sales and we had to start doing it soon.

I still remember that first conversation with Allen. In abbreviated form, it went something like this;

Me: Hello Dr. Ward, I’m calling at the recommendation of Jim Womack for some help in improving our product development at Harley-Davidson. Would you be available to work with us?

Allen: No

Me: May I ask why?

Allen: I’m Busy …

Me: !!??

Allen: … I don’t know that you are serious.

Me: I’m very serious. We need to significantly improve our product development to make our business goals. Jim said you are the most knowledgeable person on Lean product development. Can you help?

Allen: I can help, but I don’t want to waste my time. Do you know what you are asking?

Me: I think so, I need help applying Lean to product development.

Allen: Do you know what Lean product development is and what it’s going to take?

Me: !!?? (I’m thinking – is this guy nuts? That’s why I called!) Well, sir – I was hoping that you could teach us.

Allen: I’m tired of wasting my time on companies that want improvement but won’t do the hard work to get the results.

Me: I can assure you that we are serious about making improvement.

Allen: I’ve heard that before. Call me when you know what you are asking and commit to doing the work.

Me: How do I do that?

Allen: Buy my book.

Click …

… Allen’s book, The Lean Development Skills Book, was a 90-page, spiral bound 3 ½” x 4 ½” booklet of the most unintelligible gibberish I had ever seen.

Although it was tempting, I’m really glad I didn’t give up after that exchange. Allen became a good friend, a fantastic mentor, and an invaluable asset to the 4-fold improvement in product development we came to realize.

I still reflect back on that initial conversation at times. Why is it companies want the results but won’t do the work? Why is it that organizations expect improvement but won’t see it through? Do companies realize how inefficient their product development processes are? Probably not – I didn’t. It wasn’t until we had improved that I realized how bad we had been. What will it take for organizations to embrace Lean product development? I suppose not understanding the prize and not knowing the work it will take have a lot to do with it.

For those caught in the quagmire of traditional methods, not knowing their potential is just as difficult for them to see as it was for me. Today I have a hard time understanding why organizations don’t invest in Lean Product Development, but then again, I’ve seen both sides. There is a better way if you are willing to put in the work, and the potential is greater than you might imagine.

I suppose in some way that first conversation with Allen was testing my desire, drive, and commitment – I would not put it past Allen.

If you would like Allen’s take on Lean Product Development, you can see him on youtube here. https://www.youtube.com/watch?v=Mu_-7B0owAw&t=24s

If you are interested in exploring Lean Product development further, you may be interested in an on-line webinar with information here. http://leanfrontiersdirect.com/lean-product-development-lean-frontiers-direct/

Can a company really be Lean if Product Development hasn’t embraced Lean?

It’s been documented that Toyota realizes 90% of lean’s financial benefits largely from Product Development. When you consider the impact on sales from new products and the cost implications driven by engineering decisions, that number is not surprising. Kaizen activities on the shop floor, while important, only drive a marginal impact on the overall benefits of lean. So if you ignore the area with the greatest potential impact on your organization, can you really consider yourself lean? Inevitably, excluding product development in the lean journey undermines the potential impact of lean methods to the organization.

Why then are so few lean organizations pursuing Lean Product Development (LPD) principles and practices? Although it can be difficult, it can’t be for lack of learning opportunities.

• Develop Lean has assembled an impressive team to transfer LPD knowledge through workshops, materials, and coaching.
• The Lean Enterprise Institute has an LPD focused website.
• The non-profit Lean Product & Process Development Exchange offers annual events in North America and Europe.
• And most recently, Lean Frontiers has partnered with Develop Lean to bring to the lean community a convenient on-line event, called Lean Frontiers Direct, to raise awareness (learn more below).

It is the aim of Lean Frontiers and Develop Lean to create forums of learning together with organizations like those above, to grow the body of knowledge, raise awareness, and promote the use of Lean Product Development methods.

Next Up: Lean Frontiers Direct

June 21, 2017, On-line Event, 10:00AM – 3:30PM Eastern Time  LEARN MORE

Lean Frontiers and Develop Lean are pleased to invite you to this convenient, on-line workshop to walk you through the broad understand of Lean Product Develop, through identifying/solving/learning from problems, to action steps for you and your team. directly to your conference room, laptop, or phone. A highlight of the day’s agenda is below. See the full agenda here.

• We begin the day with a broad look at the role of Lean Product Development within the context of the Lean Enterprise. We seek to establish why a Lean enterprise should be concerned with product development and what it means to the enterprise.
• Next we take a step deeper with an overview of Lean product development, how it differs from traditional methods, and the improvement the enterprise could expect. We intend to create a framework for presenting practical techniques participants can use.
• Then we dive deeper by presenting tools that participants can implement immediately to impact their product development system beginning with identifying problems through visual management, followed by solving problems with the A-3 technique, and the application of problem solving to create re-usable knowledge.
• We conclude by surfacing with actionable advice and practical suggestions on how to make progress on your product development improvement journey whether you are just starting the journey, or well on your way.

June 21, 2017, On-line Event, 10:00AM – 3:30PM Eastern Time, Only $495 per device (unlimited attendance per device)  LEARN MORE