Lean Product and Process Development – Stories from the Field

Dear Community Member,

I had planned to get this note out to you sooner, but we’ve been incredibly busy working at the gemba to improve product and process development systems. Know the feeling? It’s always difficult to find time to step back and reflect when there’s work to do, but it’s crucial if we want to be intentional about where we’re going.

Since starting the LPPD initiative at LEI less than a year ago, the demand for support in improving product development capability has far exceeded our expectations. We’ve had the honor to work with more than a dozen companies in industries from aerospace to consumer products to medical devices, to marine equipment and more. These are high performing organizations doing work all over the world – in North America, South America, the Middle East, Europe, and Asia. In every case they are confronted by formidable challenges to their product and process development systems.

The business need is clear: The world is far more competitive than ever before and strong product and process development capability is essential. Increasingly, companies need help connecting with the right knowledge in the right way.

Our first event with LPPD Learning Group partners in 2015 was hosted by Herman Miller and was an incredible, one-of-a-kind experience. Over an intense and rewarding 2-day learning event, leaders in product development from non-competing organizations shared their Strategic A3s, A3 Trees, and ongoing improvement experiments. The cross-company collaboration was remarkable. Teams openly shared their business challenges as well as specific actions they are taking to improve their development system performance. The dialogue was robust and left everyone hungry for the next event in early fall.

Here’s a bit of what we discussed:

  • How to use PDPs (Perfect Development Plans) to demystify development, create flow, and enable teams to understand and react to abnormal conditions early and effectively. Then how to use PDPs to identify key interdependent inputs and outputs in order to increase speed to market through more precise concurrency.
  • How to leverage manufacturing excellence and each organization’s unique process know-how as a competitive advantage in product development.
  • How to deliver on the details of craftsmanship (visual/audial/tactile) to improve the customer’s total experience with your product to create another powerful competitive advantage.
  • How to build web-based collaboration and physical experimentation into the front end of your development process to increase innovation and speed.

This is just a sample of what we’re working on in the LPPD Learning Group, the results of which we look forward to sharing more of with you. Does your team or organization struggle with these problems? Have other challenges? Tell us. We want to hear. Email us at leanpd@lean.org and let us know.

Beyond LEI’s LPPD Learning Group, here are other things going on in the larger Lean Product and Process Development ecosystem:

  • LEI’s John Shook, Danielle McGuinness, and I spent a day with Rich Sheridan and James Goebel at Menlo Innovations in May. Most of you are familiar with Menlo either through the Menlo case study or Rich’s hugely successful book Joy Inc. It was an energizing day, and an excellent exchange of ideas. Look for increasing collaboration between these two customer-focused, people-centric organizations.
  • The product development community is gearing up for the next Lean Product and Process Development Exchange conference in Austin September 15-16 featuring John Shook, Rich Sheridan, Harley Davidson, Steelcase, Intel, and more. Check out the agenda and please join us.
  • John Shook kicked off the LeanUX NYC conference earlier this spring for the second year in a row with a talk, “Lean is About Building an Organization that Learns to Learn.” LeanUX NYC explores what it takes to design great products customers love, design teams that design great products, and design resilient organizations that support happy teams that design great products – primarily in software. Read an interview with Will Evans about the how the Lean and LeanUX communities are collaborating.
  • Can great products help to revitalize a city? Detroit seems to be undergoing a product-led comeback. I have an emotional tie to the city since I was born there. But Detroit is garnering tons of international attention for product-led businesses like Shinola and Wallace Guitars, among others. Hundreds of businesses like these are bringing a vitality back to the city that it hasn’t seen in decades. Never underestimate the power of entrepreneurial energy, deep skill, and great products!

We’re just getting started with our effort to respond to the demand for more Lean Product and Process Development support, and we couldn’t be more excited to invite you to join us as we think, learn, and do together.

Stay in touch, email us your questions, and I hope to see you in September!

– Jim

Jim Morgan
Senior Advisor
Lean Product and Process Development
at the Lean Enterprise Institute

Lean Product Development at Cathedral Hill Hospital

The Cathedral Hill Hospital (CHH) project is a 1.2 million square feet urban replacement hospital in San Francisco. Started in 2007, this state-of-the-art structure breaks new ground in design, construction, and operations. CHH’s Integrated Project Delivery Team has applied lean ideas, concepts, tools, and processes to develop this very complex project every step of the way. This paper compares and contrast initiatives set forth at CHH with the 13 principles proposed by Jim Morgan and Jeffrey Liker regarding the Toyota Product Development System. It explores the opportunities and limitations of experimenting and implementing LPPD ideas and practices in design and engineering. Read more.

Value Stream Mapping and Obeya: Key Enablers for Better Product Development

For an organization to be continually relevant and profitable, it needs to develop products and processes that consistently create value. This can be done by (a) being responsive to changes in the environment including technology developments, changing competitive landscapes, and the needs and expectations of customers and (b) developing and supporting team members within the organization so they have the ability and skills necessary to be responsive to those changes. But how exactly do you create these new organizational capabilities and supporting leadership behaviors? Read more.

Combining Scrum Software and Lean Hardware for Total Product Domination

Embedded software in hardware products is a fact of modern life. From smartphones and home thermostats to stereo speakers and jet aircraft, innovative software is increasingly what makes our hardware work as well as it does. As just one example, the latest generation of the Ford Focus uses more lines of code than the entire Windows operating system.

Combining Scrum software development with Lean hardware development is an extremely powerful approach for delivering value-creating, consistently innovative products that delight customers. I’m often asked how to build hardware with embedded software where the software team uses Scrum and the hardware team leverages “LPPD”. The first thing I usually say is that there are a number of implementation aspects that need to work together to do this well and have the larger team reach their full potential. Scrum and Lean derive from the same source (the work of W. Edwards Demming and operating principles developed at Toyota and other Japanese manufacturers in the 1950s) and are inherently compatible delivery systems, but the system can break down without a holistic and internally-consistent framework for integrating the two components.

When I have been asked this question, it is typically because a company is experiencing some or all of the following symptoms:

  1. Perfectly good working software is combined with perfectly good working hardware, but the resulting product does not work at all, doesn’t perform as expected, or is riddled with defects
  2. Projects overrun their schedule and budget due to the need to diagnose integration issues or because stable iterations of the hardware and software aren’t available at the same time
  3. Programs collapse in a rash of finger pointing and recrimination over who is “at fault” for product failures

The solution

There are a number of ways that hardware/software integration can disintegrate. Each dysfunctional implementation is unique, but a few common root causes end up driving a disproportionate share of the problems. Looking closely at these potential issues and ensuring that you have the key counter-measures in place is your first step:

1. Aligned development cadence – Both Scrum and LPPD are iterative design approaches that produce incrementally better generations of the product en route to a final version. Both give us a steady cadence to drive incremental improvement (the “Sprint” in Scrum and “Takt time” in LPPD). Yet despite this parallel process structure, it is surprising how few embedded software/hardware projects actually bother to align their development cadence so that incremental product generations are delivered at the same time.

Aligned cadence makes it easy to forecast what generation of hardware needs to marry with each generation of software, and plan feature delivery accordingly. A lack of alignment makes this almost impossible and results in ad hoc combinations of hardware and software that, unsurprisingly, don’t work well together. Aligning cadence does not mean that the software and hardware teams both need to deliver a new product generation in the same length of time. Software teams generally deliver faster increments than hardware teams given hardware fabrication lead time. It does mean that the hardware cadence should be a multiple of the software cadence (as shown below) so that each new hardware generation is delivered at the same time as a new generation of the accompanying software.


Figure: Aligning software/hardware project cadence

Integrated products can also take advantage of faster software cadence to improve product reliability. A good rule of thumb is that a software teams should not pull a backlog item into their active sprint that depends on hardware features that haven’t been delivered yet. Far better to wait until the supporting hardware capability exists and only then use the current hardware generation to run regular integration tests to rapidly develop software features in the following sprint.

2. Collective product ownership – It makes sense to divide software and hardware development into separate teams given the different skillsets required of each. But at the end of the day the product will succeed or fail as an integrated unit, so it’s imperative to keep a collective sense of product ownership. This mindset is often overlooked in favor of a focus on processes or tools, resulting in the “those foos” problem. You know the one… The software team says, “we could have had our part of the project finished months ago if only those fools in the hardware team could deliver a circuit board that meets our I/O requirements!” Meanwhile, the hardware team is blaming the equipment team for not providing enough physical envelope and voltage for the required circuit board, and the equipment team is pointing back at software for changing their requirements all the time.

This problem is a classic symptom of a lack of collective ownership of the product, resulting sub-optimization of the overall product, and reliance on internal service level agreements rather than open communication across teams. What you want is frequent cross-team collaboration and a sense of a shared identity. Some level of team competition can drive continuous improvement, but be careful not to unintentionally encourage the old “those fools” thinking. (for example, bonus structures that only consider individual or team results rather than program-level outcomes).

3. High Transparency –  Cross-team communication is only one element of a larger need for transparency in embedded software product delivery. Both Scrum and Lean include making work visible as a core principle – Scrum boards, product backlogs, and burndown charts for Scrum… Hoshin boards, and information radiators for Lean. Yet surprisingly, most integrated product teams don’t extend this transparency across hardware and software teams. Transparency is more than just facts and data… it includes context and mutual understanding and allows the entire development team to determine where other teams stand, how they are approaching key challenges, and when to deliver key dependencies for optimal integration.

How do you do this? Your approach to transparency should include at a minimum:

  • Information radiators for each team that show current status, on-deck work, flow rate (e.g. velocity), quality, sustainability, and other key metrics that are accessible to all teams
  • Regular sessions to align the evolving workplan for each team in light of new learning and to manage cross-team delivery dependencies
  • Regular sessions to “demo” new product features or functionality and share new insights  (e.g. Sprint Review meetings in Scrum) so all team members have the context to keep working in alignment
  • Opportunities for members of different teams to meet each other directly and informally to cross-pollinate ideas and understand each other (for example, co-locate teams in adjacent spaces rather than in separate departments)

There are too many ways embedded software developments can struggle to address all of them here. But focusing on close integration through these three actions – aligned cadence, shared purpose and ownership, and effective transparency – will build a strong foundation for better product development. Layer the continuous improvement mechanisms of both Scrum and Lean on top of this foundation and you are well on your way to better products and more effective teams.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

Lean, Agile, Joy

Lean community… we need to talk. Seriously, let’s have your people contact my people. We really do need to talk.

Perhaps, the unfortunate consequence of Womack, Jones and Roos’ book, The Machine That Changed the World, is that some might conclude from the title that the change is done. (The Machine that is Changing the World might be a good next edition, Jim).

Since it’s original writing in 1990, the world of work itself has changed. And the most significant change might be summed up in a single word: software. Think about it: how many of us remember film? Newspapers? Travel agents? Land lines? The Readers Guide to Periodical Literature? Video stores? Maps? TripTiks from AAA?

What will be on this list in another 25 years? Letter carriers, credit cards, wallets, driving your own car?

There is no longer a company in existence that can survive without software. And most companies aren’t good at it. As recently demonstrated, Starbucks can’t even sell coffee without software. Their April 2015 point of sale system outage forced them to give away coffee on a Friday afternoon for 3 hours costing them millions in lost revenue.

This software thing is a problem, and a big one. Every major corporation is trapped by the software dilemma. Damned if you do, out of business if you don’t. Pick up a copy of The Wall Street Journal (all right, there are still real newspapers) and see if you can even get past page 1 before you learn of another software catastrophe within a major corporation, or the government. I used to have to over explain this point until Healthcare.gov came along and even the current administration was caught in the chaos of the software game. The President had to talk to the nation about bugs and glitches, missed deadlines, horrible project management, gaping security holes, and outlandishly poor performance. I never thought I’d see it, but we were having a national conversation about improving process design!

The last place my industry reaches for help is the stodgy, rusting, old manufacturing sector. I mean, we are the future, the software industry! We don’t need no stinkin’ manufacturing types to teach us a thing or two about systems thinking, operational excellence, quality, capacity planning, lightweight process, human energy, teamwork, trust, collaboration, and continuous improvement! (Do we?)

Yes we do. Some of the problems we can discuss are familiar to the lean community:

  • Towers of knowledge that become bottlenecks of productivity and prevent scaling.
  • Lack of tangible capacity planning capability which results in death march cultures, employee burnout, and the quality problems that are a natural consequence.
  • Ineffective practices that operate without rigor and discipline leaving our companies vulnerable to all forms of software chaos.
  • Ineffective conversations across divisions within companies: Finance, Marketing, Sales, Production, and R&D don’t see each other as partners but adversaries.
  • And so much of the effort needed is not about process or tools, but first about culture and attitude. It’s about building trust, collaboration and safety.

That’s the thing. Learning from manufacturing might be one of the smartest things we can do. Our industry is still a fledgling industry. We are still in our youth. We are Detroit, circa 1950: proud, wealthy, solid, undefeated, on top of the world. No one can beat us at our game. We are the best and always will be.

There are some crazies in our industry who believe we need to improve things. We call ourselves the agile community. We talk about new methods, new process, new approaches. And big industry still largely thinks we are cute. Probably the way Detroit thought about quality guru W. Edwards Deming in 1950.

Wherever you place yourself, the software community needs to up its game. We need an order of magnitude improvement. The future of human civilization may depend on it. I know that sounds like hyperbole, but I’m not sure anyone can know just how important software quality and security can be until something really bad happens.

As for me, I also want to move this big conversation towards joy. The joy of creating software that delights users, that works without error, that is secure and scalable. And the joy of collaboration because improving software design, systems, and processes to consistently create real value will be a ton of hard work, the kind of work that the lean community knows how to do, and that the agile community is geared and motivated to do.

This is the real reason we need to talk: we simply need each other. The direction industry is headed is that very few manufactured products don’t include software. Imagine a car without software, an airplane, a medical device, a phone, or a kitchen appliance. And the software community needs lean know-how.

So let’s talk. My people will call your people. We are on the verge of an exciting new frontier. Let’s get going.

Our first opportunity for this conversation may be at the LPPDE conference, September 15 and 16 in Austin, Texas. I’ll be there. I hope to meet you then.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

Problem Framing at the Fuzzy Front-End of Lean Product Design

Many organizations face the challenge of balancing the exploitation of their existing business model and value streams with exploring potentially new value streams. To do that, many have sought me out to bring a combination of design thinking, product design, and Lean Thinking. Their goal is to increase organizational capabilities around the design and delivery of products that solve customer problems with new or simply better existing products. This is sometimes called the fuzzy front-end, or the moment of customer pull. To do this requires we requires that we return to two fundamental questions:

  • Who is the customer?
  • What is the problem? (or what is the job-to-be-done?, in Clayton Christensen’s words).

Many of these organizations have trouble answering these two questions with any degree of confidence. Most people have their own tacit understanding of who the customer is and what problem they have, but there isn’t a shared understanding across the product innovation or product development teams – everyone is literally on a different page. What some consider a rather straight-forward process of writing a well-formed problem statement is problematic for many people. When I’ve ask for a few paragraphs explaining the nature of the problem, who has the problem, and the context in which the problem arises, what I often receive back is a solution statement describing the future state or target condition – making it difficult to generate new potential solution concepts for new products.

As [inquirers] frame the problem of the situation, they determine the features to which they will attend, the order they will attempt to impose on the situation, the directions in which they will try to change it. In this process, they identify both the ends to be sought and the means to be employed. – Donald Schön

To help with this, I recently developed the 4W method with the 4W Problem Canvas for teams and organizations to create a shared understanding of the problem domain, and to write a clearly defined problem statement. This is so they can begin the collaborative ideation process to envision new product and service solutions and use PDSA to test them, before iteration and scaling. (I find organizations and teams often jump immediately to solutioning, iteration, and scaling).

I’ll begin with a brief overview of 4W and A3 used in Lean Thinking and discuss how I believe they may actually be complementary, not competing, methods when teams are at the beginning of exploring a new horizon, product, or service to create new value streams. I’ll finish by unpacking, step-by-step, the 4Ws Method.

The 4Ws, A3, and Lean Thinking

In the past few years, I’ve employed A3 in many different contexts to help teams understand the current condition, map dependencies and causal relations, posit a new future state or target condition, and define how success will be measured. This is incredibly powerful stuff.

One downside is that for people in knowledge organizations (like software design) with little experience with Lean Thinking, A3 requires some training. Often times, I just need teams to arrive at a shared understanding of the problem and surface their tacit assumptions. The other issue I’ve found with A3 is the format itself. An A3 sized sheet of paper is not necessarily conducive to true collaboration across a number of people within a team. Its big enough for one person to fill in, but even when a few people are working on an A3, the probability of premature convergence around the ideas of the one person with the pencil is high.

I originally thought of the 4W method as a light-weight, watered-down version of A3, but these days I think it can be used as a gateway drug to A3, or even better, to help drive a clear definition of the problem statement and current state to be written into the A3. If you think about the flow: from problem statement to current condition, to target condition, to countermeasures and how to measure success or failure – it begins with a clear, unambiguous, shared understanding of the current problem.

Unlike product innovation in knowledge work, within the context of deterministic systems, like manufacturing, it’s relatively easy to state the problem, current condition, and posit some target condition that is better than the current situation. This is the ordered domain of known knowns, or at least known unknowns – where there is at least a knowable causal relationship between things in the system. This is where I believe A3 excels, because this is the context in which this method arose.

In knowledge work, sometimes the target condition is some better future state that is both unknown and perhaps even unknowable. This is because many aspects of knowledge work like software design often exists in a more complex domain. So instead of generating one potential target condition, we create and test many possible options because we simply don’t know how the system will react to our intervention or probe. This is where combining A3 with other methods, like 4Ws and Design Studio, may help people leverage A3 as an overarching framework for problem discovery and problem solving, while applying other techniques within the A3 method for problem framing and concept creation.

I hope you find this method useful, and welcome any feedback you might have, especially if you try it in your organization.

Process for Facilitating the 4Ws

Materials for Success

  • Post-its: multiple colors, multiple sizes
  • Index cards: multiple colors, large size
  • Sharpies: multiple colors
  • Large-format easel pads with adhesive

You will also need:

  • A quick 5-minute introductory presentation explaining 4Ws (PPT or PDF)
  • Lean Personas (or Empathy Boards*)
  • Research: any video, audio, interviews, contextual inquiry, or design ethnography to better understand the people for whom the designed solution should work, as well as any research which includes qualitative and quantitative data around the nature of the problem to be solved – the What that needs to be defined.

The 4W technique works best when a number of stakeholders who will be involved in designing, testing, and releasing a new product are participating. The key is having at least 6 people, to as many as 24, divided into teams no larger than 4.

Round One

Using the large format easel paper, draw with a sharpie 4 quadrants, and label each one with Who, What, Where, and Why, clockwise (link to PowerPoint again here). You will want to timebox this exercise. I have provided some recommendations at each stage of the process.

First, have individuals explore each quadrant by themselves silently. Each person writes at least 2 ideas that answer each of the 4Ws on 3×3 post-its. This should take about 10 minutes.

The 4Ws are:

WHO: Who has this problem? Is it the customer? What do you know about the customer? Be as explicit as possible (sometimes people come up with more than one customer, and that’s okay to start).

WHAT: What is the nature of the problem? Can it be explained simply? How do you know it’s a problem? What is the evidence to support that the problem exists?

WHERE: Where does this problem arise? In which context does the customer experience the problem? Has it been observed? Can that context be described simply?

WHY: Why do you believe this is a problem worth solving? Is it an acute problem? How acute?

After people finish and there are at least 2 post-its per quadrant, have the team spend 10 minutes presenting each post-it to other team members, and then place their post-its on the 4W Problem Canvas. After all team members do this, give teams 10 minutes to discuss all of the ideas. Ask them to notice, but not remove duplications, and to highlight and discuss contradictory insights. The point is not to drive consensus, but to have the conversation so that a shared understanding emerges – this is collaborative sense-making.

Sense-making is simply the collaborative activity that enables us to turn the ongoing complexity of the world into a “situation that is comprehended explicitly in words and that serves as a springboard into action” (Weick, Sutcliffe, & Obstfeld, 2005, p. 409). Thus sense-making involves—and indeed requires—an exploration of unknown problem landscapes, because sometimes trying to explain the problem is the only way to know how much you understand it.

One downside is that for people in knowledge organizations (like software design) with little experience with Lean Thinking, A3 requires some training. Often times, I just need teams to arrive at a shared understanding of the problem and surface their tacit assumptions. The other issue I’ve found with A3 is the format itself. An A3 sized sheet of paper is not necessarily conducive to true collaboration across a number of people within a team. It’s big enough for one person to fill in, but even when a few people are working on an A3, the probability of premature convergence around the ideas of the one person with the pencil is high.

Individuals get 1 vote per quadrant to vote on what they consider to be the most salient or relevant idea.

Round Two

Each team member takes a large format index card and spends 10 minutes writing a problem statement by themselves. The paragraph must explicitly reference the Who, What, Where, and Why as presented on the 4W Problem Canvas. The constraints are that problem statements can’t be more than 6 sentences, 150 words, and shouldn’t use more than 3 semi-colons (this is arbitrary, but sometimes people ask for this level of detail with constraints).

At the end of 10 minutes, each person reads their problem statements to the rest of their team. Each person gets 1 vote. The strongest one or two problem statements emerge. Teams then have another 10 minutes to re-write their problem statement based on the strongest 2 from the previous round, but again are constrained by keeping statements to two paragraphs max.

Round Three

In the final round, teams present their problem statements to other teams participating in the activity, or to external stakeholders who haven’t been part of the process. At this step, teams are checking their problem statements for clarity and coherence. You may use a formal critique method, but it can be just as effective to interrogate the problem statements to make sure they clearly articulate the Who, What, Where, and Why while also ensuring that no notion of a solution is embedded within them. If it is, it must be removed.

Teams building their 4W Canvas

That’s the 4Ws. Simple.

The entire method, even with 24 people, should take under an hour. The benefit is that teams gain a shared understanding of the problem and leave with a clearly articulated problem statement. As a result, two things happen. First, when a team’s thinking process is transparent they can reach agreement faster. Many arguments and disagreements about the nature of the problem are actually disagreements about assumptions tacitly held. If we can’t make our assumptions visible, then they can’t be discussed. Second, making the thinking visible about the problem and customer enables coaching. You can’t coach outcomes. If someone just showed you that they’ve failed to define their problem, you don’t know why unless you can see their thought process.

Many organizations, even ones that are successfully practicing Lean Thinking, sometimes find it difficult to create a shared understanding of a problem and clearly articulate a problem statement. While A3 is a very powerful method, I believe that for some teams and organizations, there is value in trying the 4Ws method to collaboratively understand the nature of the problem to be solved, or the job-to-be-done. For organizations just becoming exposed to Lean Thinking, 4Ws may provide a light-weight, gentle slope introduction to PDSA. For more mature organizations, it may offer just one more tool in the toolkit.

I hope you give it a try in your team or organization and send some feedback so that we can iterate this method forward.

References & Resources

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

The Agile Leader’s Dashboard

I am having lots of conversations these days about executive dashboards for agile leaders. What we’re learning really applies to any change agent looking to make their work visible and keep it on track.

What does a leadership team really need to know in order to do their job well, and how can teams provide that information without wasting valuable time preparing reports? In the lean community, this is often about visual management and is as important to the effective functioning of a lean cell as transparency is to the success of an agile team. The challenge for everyone is how to give leaders the transparency they need without wasting their time (or yours).

A successful dashboard should provide leaders with the relevant context and metrics they need to make informed decisions. It should be updated on a frequency that meets the required decision-making cadence. And, whenever possible, the dashboard should be assembled from data that teams already collect to inform their own process and pulled automatically to minimize distraction from value-creating work. Not unlike the A3, lean practitioners using hoshin planning can use a dashboard like this to provide relevant updates on progress towards identified goals.

Which metrics should be tracked on the dashboard?

Top-level metrics should answer the following:

1) Are we producing the right product(s) for the customers we are trying to serve?

2) Are we prioritizing our efforts and applying resources correctly given what we think we know about the market and our competitors?

3) Are we making consistent progress towards our strategic goals?

4) Are we doing all of the above in a sustainable way?

What it looks like:

How often should dashboard data be updated?

Some decisions only need to be made once a year, such as “Should we renew our annual contract with…?” Others need to be made monthly, daily, or even in response to real-time events, such as “How do we restore service given an outage that just occurred?”

A truly great dashboard provides key metrics with the most relevant data being displayed and is updated frequently enough to provide decision makers with the data they need when they need it.

Make It Easy

Many teams complain about the onerous reports they are asked to produce for senior leadership. The typical complaint is that leadership wants updates on a number of metrics the team never uses for its own purposes, so this data must be gathered, calculated, and presented manually. The team sees this as a huge waste of time, especially if it isn’t clear to them why the information is needed in the first place.

In the agile world, Scrum throws off enormous amounts of high quality data, such as velocity, team happiness, planned backlog, defect and impediment lists, and business value. Most teams already collect this data using software tools with API interfaces. There are off-the-shelf products that can aggregate this data onto a desktop or mobile device, providing leaders with relevant, timely data, whenever they need, wherever they are, without bothering the team.

For lean practitioners, distributing or scaling across teams/cells makes it harder to rely on information radiators or hoshin boards for communication and tends to amplify any dysfunction that already exist at the team level. So it is even more important in these cases to make the most relevant metrics visible to leaders in a timely way via an electronic dashboard.

A good dashboard and focused follow-up conversation can do more to increase transparency than the hours of coordination and update meetings that most leaders currently endure.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

Frontloading Product Development

Everyone who participates in the product development process in some way is familiar with the agony of late-stage changes, sometime called loopbacks. Whether it’s an unexpected failure in prototype testing or a manufacturability issue that appears during production ramp-up or a warranty issue in the field, making design or engineering changes late in the game produces a tremendous amount of waste. Development teams strive hard to avoid them, yet almost all practitioners consider loopbacks as inevitable, and indeed even plan for them. But from a lean perspective, this is regrettable because a loopback is just rework under a different name. Developers design, analyze and test their product or process, only to have to repeat those same activities at a later date.

Just like on the production floor, loopbacks (or rework) can be tremendously costly. It is widely recognized that the cost of making changes increases over product development project timeline. As shown in the figure at the right, for most manufactured products, the cost to make a change during the design phase is cheaper than during the prototype phase, which is cheaper than when the product is in production. And most would agree that the cost curve is geometric. In fact, some have said that the cost to make a change in any given stage is ten times more expensive that the immediately preceding stage! So we can see that late-stage changes can be costly indeed.

The common advice to head off the problem of loopbacks is to “frontload” the product development process. But what does frontload mean?

Some have suggested that it is wise to start a product development project by accumulating what we already know. For example, manufacturing engineers can supply the team with information on the process capability of their current manufacturing equipment at the start of the project. Then the product designers can (hopefully) design within those constraints to minimize problems on the plant floor while improving quality and efficiency. The challenge with this suggestion is, of course, in the accumulating of the knowledge. But it is also in the translation of that knowledge from process terms into terms that product designers can understand. Lean companies devote significant effort to catalog their process capability on a continual basis so that the knowledge is ready to deploy with any new product development projection.

Others have recommended to frontload development projects by putting together cross-functional teams from the very start of the project. Teams consist of capable representatives from all functions necessary to bring a product to market: sales/marketing, product engineering, industrial design, manufacturing engineering, purchasing, and finance, for example. The idea is to ensure that all viewpoints are considered from the early stages to avoid unexpected “discoveries” late in the process. But one question often nags these teams: what should they do in those early phases?

Stefan Thomke recommends rapid experimentation in order to learn about product and manufacturing process possibilities. We can extend Thomke’s idea with Allen Ward’s notions of set-based design, what we now term set-based innovation.

In a set-based approach to development, teams engage in very different way with the development challenges they face versus conventional approaches. The core practices of set-based innovation are:

  1. Generate multiple alternative solutions for every design sub-problem identified.
  2. Understand those solutions against design requirements by generating data through analysis, modeling, and low-cost prototyping. Pay attention to the granularity of data needed – use low fidelity models when quick-and-dirty answers are needed, for example.
  3. Eliminate an alternative when the data show that it either cannot meet the requirements, or is clearly inferior to another alternative. Avoid selecting an early winner—use an elimination process instead.
  4. As you go, try to generate reusable knowledge in the form of design limits and tradeoff curves. If you understand the physical limits of a design concept, and those limits fall outside the requirements, you can safely eliminate that alternative.
  5. Allow some flexibility in design requirements so that you can use the knowledge gained to set the final requirements at a point where you more fully understand the trade-offs being made.

What are you doing to avoid loopbacks? What are other ways you have used to eliminate rework in development? Do you have examples of any of the above approaches? Share your thoughts and ideas so we can all learn more.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

The Designer’s Dilemma

If you have ever worked on a design project or any other open-ended, ill-defined problem, you’re familiar with the designer’s dilemma.

It works like this: at the beginning of a project you have a lot of freedom to take the design or project in many, possibly infinite, directions. But you also don’t know that much about the problem or the potential solutions, so making decisions during those early phases of the project of the project is challenging because your level of knowledge is low.

Fast forward to the end (or near-end) of the project: your knowledge about the problem and the solution is at its best. But unfortunately, because of the decisions and commitments made throughout the whole process leading up to that point, you’re now more constrained than at any previous time in the project, so you have the least amount of freedom to act on that knowledge.

knowledgeThat’s the designer’s dilemma—you have the most freedom to make decisions when you know the least about the problem. But as you learn more, you become increasingly constrained in your decision-making and ability to change course.

If you’ve ever said, “If I had known then what I know now, I sure would have done things differently,” then you have experienced it.

Why does the designer’s dilemma exist? Part of the reason is that solving design problems (and similar problems that are open-ended and ill-defined) requires, to a significant extent, a discovery process. We have a lot of learning to do in order to understand all the ins and outs of problem, its social and environmental context, interfaces, technical possibilities, and the like. So necessarily we have to grow our knowledge in order to solve the problem. And because we do not have infinite capacity or time in which to solve the problem, we have to pick and choose where to focus our discovery efforts. In other words, we make decisions that take us in a certain direction. Those decisions lead to other decisions and so forth… and next thing we know, we’ve invested a lot in a given solution path, making it difficult to change course.

Another part of the reason, especially in engineering contexts, is the approach often used for design problems. Typically, after considering a number of potential solutions, the team selects the one that seems best at the time. They then add detail to that idea, analyze it, and refine it until it meets design requirements. The difficulty here is that we don’t know when or if such a process will arrive at an acceptable solution. This does little to resolve the designer’s dilemma. And the effects are made worse in an organization context, which is where a lot of product development happens. Changes by one person lead to changes by an interfacing subteam which leads to changes by a third person or team, and so forth in a domino effect that may never come to an end. Some call this phenomenon design churn because of the turbulence it creates within the organization.

Fortunately, there is something we can do about it! We can mitigate to a significant extent the deleterious effects of the designer’s dilemma by applying the practices of set-based innovation. One practice in particular is especially useful for combatting the designer’s dilemma: trade-off curves.

Using trade-off curves, we try to understand the design problem in a more general sense, based on the underlying principles that govern the situation. For a given design concept, how are the performance metrics that the customer cares about affected by changes in the values of design decision variables? This relationship can be displayed graphically for quick and easy communication, and for fundamental understanding.

For example, a golf club manufacturer knew that the center of gravity of the golf club head has a significant effect on how far the ball will go when hit. Too high or too low from the ground, the ball will not travel in an optimal arc to produce maximum distance. By running a series of experiments using an easily modifiable golf head, the development team generated trade-off curves which show exactly where the optimal center of gravity is, and how sensitive travel distance is to deviations from optimal. This is knowledge gained about general golf club design (as opposed to a specific golf club head design) without reducing design freedom since no decisions have been made. As the team accumulates such in-depth knowledge, the design problem comes increasingly demystified. At some point the team would simply need to select where they want to be on each of the curves, draw up the detailed design, and release it.

Dr. Allen Ward (author of Lean Product and Process Development) claims that trade-off curves are the most powerful tool in the lean product-process developer’s tool kit. Do you agree? What experiences have you had with trade-off curves? What advice do you have for people starting to learn about them? Let us know what you think.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.

Leave Your Ego at the Door

The lesson started with a simple, hand written note I received through intra-company mail one afternoon. Alan Mulally had just left Boeing to join Ford as President and CEO during a difficult and pivotal time in Ford’s history. Alan’s unpretentious note suggesting we meet was the beginning of a seven-year relationship during which I learned many things from Alan, like the importance of providing people with context, of always working on a better plan, and the “magic” of truly working together. But none of these lessons were more important than seeing first hand how he approached his leadership role in the company day in and day out. He approached leadership with an authentic humility and deep respect and affection for others. It was never about him – always about Ford. And this never changed, in the darkest depths of our corporate crisis, or later as the company became ever more successful and Alan grew into a rock star CEO. This approach allowed Alan to connect with people in a powerful way that enabled him to lead Ford through one of the most dramatic turn arounds in business history.

Alan MAnd after working for Alan awhile it occurred to me that I had seen this approach before. I remembered walking through the doors at East West (recently renamed Kaizen Brazilian Jui Jitsu) and encountering the sign “Leave Your Ego at the Door” emblazoned above the training area. I quickly found that, like Alan, the best fighters were often the most humble. This wasn’t just true in my personal experience at Kaizen, Sam Sheridan in his excellent book A Fighters Heart consistently heard the same message as he interviewed the best fighters in the world; “humility was the most important attribute for a great fighter.” To some extent it is the nature of BJJ that keeps you humble. BJJ is not a “kata-based art”(choreographed sequence of unresisted movements) where participants rarely test each other physically. Rather BJJ is based on real world rolling or sparring with opponents. There is no ambiguity and no rationalization – “you got tapped (forced to submit), deal with it.” It crushes illusions and forces the critical self-examination required for improvement. But the most important reason great fighters put their ego aside is because it inhibits their progress. They work harder than anyone else, always look for gaps in their game and constantly push their limits. A big ego makes you afraid to push, to try new things, to open up, to grow. Ego makes you complacent and fat, and makes you afraid to risk. You are stuck.

bjjBut don’t make the mistake of confusing humility with weakness. The best fighters have an inner fierceness and focus that belies their calm appearance; a no excuses drive to do whatever it takes.  Likewise, with his easy smile, and sincere “honor to serve” attitude, the casual observer could be forgiven for missing the stoic resolve, incredible work ethic and laser focused drive that have made Alan one of the most successful leaders in business today.

Many years of experience have taught me that leadership like Brazilian jiu jitsu can be learned, and that your capabilities can be continually improved. But like most difficult and tacit skills, you can only learn it by doing, and your efforts will be helped along considerably by working with outstanding mentors to guide you on your journey. People who have actually done it. During my career I’ve been fortunate enough to have truly exceptional mentors for to whom I owe a debt, which I’ll never be able to fully repay. The opportunity to work with Alan was something particularly special. So if you really want to be among the very best, you might want to consider leaving your ego at the door.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.