Category Archives: lean development excellence

MRT: Applying Rapid Learning Cycles to Development – Webinar

Here’s a chance to find out how implementing rapid learning cycles will increase speed and innovation in your development process.   Please join me for a Management Round Table webinar, April 17, 2014.

Applying Rapid Learning Cycles to Development

In this session, you will:

  • Learn about the Steelcase lean journey and applications of lean in development.   Understand lean program objectives and the framework for implementation.
  • Explore how rapid learning cycles can be applied to development from the earliest concept phases and throughout development.
  • Close knowledge gaps earlier and speed up innovation in the development process.
  • Learn how rapid learning cycles go hand in hand with innovation methods.
  • Learn how to start planning your lean product development implementation.

Dump PowerPoint – Physicists, Generals, and CEOs agree

This week National Public Radio (NPR) Alan Yu had a fascinating report.   In it he sites top level scientist and leaders in both the military and business who are boycotting PowerPoint presentations for communication and  information transfer.

A PowerPoint slide is projected on a screen prior to a lecture at the 28th Chaos Communication Congress computer hacker conference in Berlin.  Adam Berry/Getty Images

A PowerPoint slide is projected on a screen prior to a lecture at the 28th Chaos Communication Congress computer hacker conference in Berlin. Adam Berry/Getty Images

A PowerPoint slide is projected on a screen prior to a lecture at the 28th Chaos Communication Congress computer hacker conference in Berlin.     Adam Berry/Getty Images

Scientists at the Large Hadron Collider noticed that the transfer of information was hindering communication.  All of the communication was one-way.   The report quotes one of the scientists:

“The use of the PowerPoint slides was acting as a straitjacket to discussion,” says Andrew Askew, an assistant professor of physics at Florida State University and one of the organizers of the forum at the Fermi National Accelerator Laboratory in Illinois.”

The scientists were discovering that instead of a two-way communication, everything was one-way.    In one-way only communication, people in the audience typically zone out and often tune out.

And this is not only true in scientific circles, PowerPoint is being thrown out at the top levels of business and in the military.  The NPR article goes out to state:

The CEOs of Amazon and LinkedIn have eliminated the presentations from meetings. In his recently published memoir, former U.S. Defense Secretary Robert Gates calls PowerPoint slides “the bane of my existence in Pentagon meetings; it was as though no one could talk without them.”

So, what is happening is that people are noticing that something happens when PowerPoint or other multi-slide presentation modes are used…people become disengaged.   And when they disengage, meaningful discussion stops.  This is ultimately a time waster.  And even if there is meaningful content in the presentation, it is missed, overlooked, or just not heard.

Danger exists if key information is skimmed over and not taken into account.   One such event has been documented in numerous spots, and this NPR article notes it as well: the potential failure of the o-rings at low temperatures on the space shuttle solid rock boosters was actually known and in a NASA report.   But the presentation of the data was not made clear or presented in a form to delay the launch of the shuttle.  This resulted in the tragic events that we now call the Challenger disaster.

So if PowerPoint isn’t used in scientific reviews, board rooms, and at the strategy table, what takes its place?  It is interesting that the military said only maps and charts can be used.    What they are getting at is that the information has to visible and easily understood.

The visual presentation of information on a single page is the key.

A3

In lean, we favor one single page of information on an A3 (approximately 11″ x 17″) size sheet of paper.   This single page houses all of the information about the topic.

The A3 forces the author/presentor to:

  • Keep it to one page
  • Be concise and make decision on what to show or not to show
  • Show their thinking
  • Favor graphics, charts, and graphs over text
  • Refer to the document when speaking

The A3 document helps the audience:

  • Focus in on the information that is important
  • Know what information to point to when asking questions
  • Know where to look in the future to recall and reference the information
  • Have confidence that the key information is being communicated

There are multiple documents that can be converted into an A3 format.   Status reports, project plans, proposals, decision documents, etc. These are all potential candidates.

The A3 format is particularly powerful for communicating new knowledge that is gained during the research and development phases of projects.   So the A3 becomes a very important tool in Lean product development.

In all of these cases, it is important to ask for the A3 style document instead of PowerPoint.  Or better yet, demand it!

So, throw away your PowerPoint, and start communicating on a single A3 page.

Lean Development Excellence Survey

Announcing the 2013 Lean Development Excellence Benchmark Survey
Please accept my personal invitation to you to participate in the 2013 Lean Development Excellence Benchmark Survey.
Are you curious about how lean can be leveraged to improve development in your organization?
Would you like to connect with others who are on their own lean development journey?
Are you attempting to improve your culture in the area of lean development?
Are you committed to making your development program better?
Have you ever wondered where your organization rates on lean development compared to others?
Can your organization be a teacher of lean development to others?
Please accept my offer to participate in this survey. This is a rare opportunity to compare your organization to others who are on their own lean development journey.

Tim Schipper Compressed (color)

The following areas of  are included in the survey:
Stake Holder Collaboration
Optimization of Value
Waste Prevention
Real-time Measurement
Product and Process Accountability
Systematic Innovation
Team Leadership
Senior Management Support
Knowledge and Innovation Value Streams
Pace of Innovation
Strategic Planning and Direction Setting

Participation is free. Your own company’s results will be shared with you at no charge. The full results and detailed comparisons of your organization with respect to others will be compiled and offered for purchase. However, the results and comparisons across all participants will be shared and included at no charge with your attendance to the Huthwaite ummit on Mackinac Islansd in August 13-15, 2013

How it works:
The survey will be sent to you and filled out by you for your organization. This is a great opportunity to get a small team together to discuss your ratings. Discuss each question and fill it out together.
The results of your assessment will be reviewed and by lean development experts Bart Huthwaite and Timothy Schipper.
The survey will also include a 30 minute teleconference interview with either Bart or Tim to review your answers and further discuss the ratings and responses.
Once all participants have completed their assessment, the results will be compiled. The name and information of your organization will only be seen within your company, and your identity will be anonymous to the other participants. The survey results will merely indicate from which industry the results were compiled. (Bart and Tim will sign an IDA or non-disclosure agreement upon request). We will only share your information with your permission.

Sign-up soon, the assessment will only be run during the month of May and June. So start today.

Design for lean manufacturing on Wikipedia

wikipedia_logo_detail

Throw out an idea … How to place an overview of design for lean manufacturing on Wikipedia?

Learn a new skill … How can you learn the skills to be a Wikipedia contributor and editor?  This took some learning about Wikipedia editing and the nature of writing with a neutral point of view (or NPOV).

Get some help from friends … How to enlist the help of others in editing and create a meaningful entry? Thank you to the Huthwaite Institute who stayed with the long editing process.

Edit, Edit, and Edit again … How many edits might it take?  The peer-editing process on Wikipedia is fairly unique. It was difficult to find an editor who understood the process and could guide us through the maze of Wikipedia editing.  So, a special thank you goes to Cullen (not his real name), who helped us through the process.   After many back and forth sessions and many hours of revisions … Lean Design is now on Wikipedia.

The result!

A Wikipedia entry on design for lean manufacturing without any qualifying statements on the entry!

Here is the first paragraph:

Design for lean manufacturing
From Wikipedia, the free encyclopedia

Design for lean manufacturing is a process for applying lean concepts to the design phase of a system, such as a complex product or process. The term describes methods of design in lean manufacturing companies as part of the study of Japanese industry by the Massachusetts Institute of Technology. At the time of the study, the Japanese automakers were outperforming the American counterparts in speed, resources used in design, and design quality.[1] Conventional mass-production design focuses primarily on product functions and manufacturing costs; however,design for lean manufacturing systematically widens the design equation to include all factors that will determine a product’s success across its entire value stream and life-cycle. One goal is to reduce waste and maximize value, and other goals include improving the quality of the design and the reducing the time to achieve the final solution. The method has been used in architecture,[2] healthcare,[3] product development, processes design, information technology systems, and even to create lean business models.[4] It relies on the definition and optimization of values coupled with the prevention of wastes before they enter the system. Design for lean manufacturing is system design.[5]

Please proceed to Wikipedia to read the rest of the entry.   Enjoy the reading, and let us know how we could make the Wikipedia more accurate and complete.  Note:  Others have already contributed and helped to make the entry more accurate.

What is Lean Development?

What is LEAN Development? 

Several people recently asked me independent from each other, “What is lean development all about?”  And as I read, study, and explore the topic, the word system keeps coming to the forefront of my brain.  And the word system informs the definition of lean development.

Lean Design DNA System

Lean development  is the application of a set of methods and techniques that work together to create a system that optimizes value and reduces wastes across the entire life cycle of the system.

So if that is the definition, what images come to mind?

First of all, we need to think of things as systems.   The automobile with all of its components is a system.  It is made up of multiple subsystems from the engine, the transmission, the steering, braking, environmental comfort, computer, etc.  All of the systems have to work together.  A design process that is lean seeks to create a system that provides the most value with the least amount of waste.   Value can be measured by attributes such as affordability or maintainability.  Wastes can be measured by things that detract from the value such as complexity or danger.  For instance, complexity often makes the auto less maintainable, or at the least more costly to maintain.    Designs that provide the most value with the smallest amount of wastes built into them are the most desirable.  And for a complex system like an automobile, each sub-system must also be optimized for value and minimized for waste.

The automobile is a product system.  But there are many systems.  A hospital is a system.  A building is a system.  A business is a system.  The manufacturing process is a system.   Even your finances are a system.  The list goes on and on.

Other images that comes to mind are systems from nature.  Nature is filled with systems.  A tree is a system.  Our bodies are a system.   A lake or stream is a system.  A habitat is a system.  A collection of animals is a system.  When multiples of these come together, we give them a special name – an ecosystem.   In the grand design of nature, our creator placed us in an amazing set of systems.  Everything from the solar system we live in, to this planet, to the ground we use to create food, to our communities; each is a system that provides infinite possibilities and usefulness.  And each system has a very optimized design.   So some of the best examples of designs that are lean come from nature.   And, nature’s efficient systems can be placed in our own man-made designs.

Second, lean development seeks to optimize the value in the system.  Values are the things that the end user or customer needs or wants.   Lean development also utilizes an integrated product team to find best ways to increase the values in the system.   Lean development also thinks about the value of the system over its entire life, from beginning to end, from creation to disposal and recycled into something new.   In the ideal system, everything works together.  If things are not working together, or competing with each other, then the system breaks down.  If we think of our bodies in this way, we all know that all of the parts of the system must work together.   If any individual part of our bodies isn’t working, well the whole system fails.   We can echo the psalmist who said, “we are fearfully and wonderfully made.”

Third, lean development seeks to minimize the wastes that are built into the system, or might creep into the system overtime.  Some wastes start out in the system. Computer systems might have software bugs or viruses.  Once they enter the system, or are exposed, they can create a lot of havoc.   The automobile might have a poor quality part in a critical system that causes the whole system to fail.

As practitioners of the discipline of Lean Development, we are attempting to create Lean Products and Processes through the application of lean thinking.  We do that through a series of tools and techniques.  Some of them borrowed from lean manufacturing, and others from various design disciplines. But, the tools are a means to an end.  The ultimate goal of lean development is to create the best system possible.

2012-VW-Beetle-2_5-headlight

Here is an example to bring it all together:

The headlights in the VW Beetle (or call it the headlight system) is not a design that follows lean principles.  The headlights stay on at all times, which is a great safety feature that probably saves lives (value), but the replacement of the bulb is very complex because the whole headlight system must be removed to replace the bulb which is very difficult to do (waste).  On one side, the battery must be removed to access the headlight canister (complexity).    My regular mechanic won’t even touch the thing, and I have to take it to the dealer who charges a fair amount  (waste) to replace the bulb which costs just a few dollars.  Since the replacement now requires an appointment at the dealer, the repair is delayed (waste).    The fact that the headlights stay on all the time is  a great feature (value), but the fact that the bulbs have to be changed more often at a higher cost is a huge annoyance (waste over the entire life cycle).   Overall, the increased safety is still worth the hassle and cost, but with a little more attention to designing out the wastes, the team of engineers (obviously not an integrated product team) could have created a design that is lean from the start.

Lean Development practice in IT – cuts development time by 50%

Rapid Learning CycleThe year was 2005.  A large mid-west manufacturer was attempting to implement a large ERP system.  The first implementations were in the order entry and finance sections of the company.   Things moved along fairly smoothly, but then the company attempted the first manufacturing plant, converting the old legacy system into the new ERP system, SAP (from the German company … Systeme, Anwendungen und Produkte).

The first manufacturing plant took 20 months from start to finish and followed traditional phase gate or a waterfall system of development in which each phase had to be completed before the next could start.  In the  20-month SAP implementation for the plant, the team spent nearly 3 months gathering requirements prior to starting the development and then, and only then, embark on a massive customization of the system.  This meant that no custom code linking the SAP system to other business systems was written until the requirements phase was completed.

When the system was unveiled, 16 month  after the start of the project, the users in the plant immediately pointed out that it did not work the way they thought it would, and it did not meet all of their business needs.  IT, for their part, insisted they had built the system exactly as the users told them it should work at the requirements gathering stage.

Needless to say, the management team responsible for the implementation of this system was not pleased.  Nearly a dozen plants needed to be converted to SAP, and at 20 months each, the entire project would have taken a decade.

Exit waterfall development.  Enter lean development techniques for IT systems.

When the teams looked back on the process and analyzed the approach (using value stream mapping techniques), they found that their efforts contained as much as 80% rework because, although the initial requirements were very thorough, they had not anticipated all of the discoveries that were made later in the process.  And because the users were not consulted during development, many nuances of their process and techniques were not accounted for in the new SAP system.

The failure of traditional techniques triggers the motivation for change and lean development techniques.

Lean development principles were brought in and taught to the team.  Rapid learning Ccycles were used to break the large project into smaller learning events.  At the start of each learning cycle, the teams discussed what they needed to learn, and set-out to work on just that set of learning.   Users were included in these events as well, thus sharing new requirements as the learning cycles progressed.   In each learning cycle, testing and user reviews helped the teams build the system module by module.

Lean development breaks down large projects into smaller pieces.

The whole project was chunked into a half-dozen rapid learning events.  Each one was 30 days or less.  This let the team create lean flow within the team, and it reduced flow interruptions.

At the end of each learning event, the knowledge gained was reviewed with the whole team and with management.  The sharing of knowledge is another important element of lean development.

Lean development practices knowledge capture and sharing.

From the initial failure of SAP development, the team quickly recovered by apply lean principles for the design.  They implemented the next plant in a little over 8 months, cutting the time by more than 50%.

Lean development efforts typically finish in 50% less time with improved quality.

The team was complimented on their success, and lean development quickly become the standard for all the subsequent plant SAP implementations.  As the team moved on, they standardized on the design methods for IT development.

You can read the whole story, and many others,  in the book Innovative Lean Development on Kindle or in book form.   Or, better yet, ask us to talk in person to your IT organization about lean techniques in software and system development.

LEAN Development in IT: First Be Directionally Correct

The first  goal of a lean design is to be directionally correct.  Starting out in the right direction is the first priority.  Teams should worry about the precision of hitting their target later.

compass

This is in stark contrast to traditional software development methods in which teams are encouraged to gather all of the project requirements upfront.  Often teams will spend weeks and months merely gathering system requirements.  However, in lean development, the assumption is made that not all requirements can be known up front.

As the story goes, the IT developer went to the client and asked for all of their requirements.   And the client said, show me what your system can do, and then I can give you my requirements.

Developers know intuitively that not all of the requirements for a system can be determined up front.   While some gathering is needed, teams can often suffer from “analysis paralysis” if they spend too long at this phase.

Lean development seeks to be direction-ally correct in the beginning, and then worry about converging in on a solution later.  A US Navy captain, Maurice Gauthier, put it this way, “Three successive pursuits of the 80 percent solution produce the 99.2 percent solution.  However, pursuit of the 99 percent solution on the first attempt is a very poor investment of resources.”

The way to apply this to software development is to collect 80 percent of the requirements at the start, and then launch a series of rapid learning cycles.  The end goal or target is set, or as Bart Huthwaite calls it, ‘the End-in-View” is determined upfront’.   Then the team designs a series rapid learning cycles to learn, show feasibility, and to determine the course to take to hit the target.  Taking the client, or future user, along with you on the journey is key.  At the start of the learning cycle, tell the user what you expect to accomplish and what the team hopes to learn.  Outline the questions that you hope to answer during the learning cycle.  During the learning cycle and at the end, share your prototypes and your knowledge and ask for their reactions.

Every rapid learning cycle includes experiments and prototypes.  In the IT system, this means that you are doing some type of rough prototype even in the earliest learning cycles.   Showing the user the prototype might seem like a risk, but not if you tell them that ultimately it is an experiment that might even be thrown away later.  At this stage the direction is set, but it has not been fine tuned.   Then, listen to the user and let them help you inform the direction of the solution.   In listening, additional requirements will be gathered and this will help to set the system in the correct direction.  This is where you can gather the additional 20% of the requirements.

Each learning cycle should include some form of knowledge capture for the team for later reference.   The metric sized A3  (11″ x 17″) sheet of paper, is the appropriate size to capture enough knowledge without over documenting.   A lot of information can be recorded on one side of an A3sheet of paper.   The A3 acts as a beacon marking where the team has been, and describes what has been learned.

I have seen this approach work with teams both large and small.    It improves both the quality of the end solution, but it can also dramatically reduce the need for later user validation and testing because they were included in the early learning cycles.  It is not agile development which assumes the requirements are set and the developer is merely writing code.   This comes at the later stages of the project.

For a further description of rapid learning cycles, please refer to Innovative Lean Development.    Thank you.  And please send comments on how you have used learning cycles in your software development process.

Lean development strives for knowledge and idea reuse

Lean designers start with a review of the prior knowledge and proven ideas and end with documenting updates of that knowledge or new knowledge.

I have run a simple experiment which measured the effectiveness of knowledge sharing with groups simulating a develop environment. The simple experiment is an open-ended problem that requires problem solving to reach a solution. Knowledge sharing improves the outcome. After teams share ideas and knowledge, their success rate and quality improves by 100%.

A Knowledge A3 is simply knowledge captured on a single page of metric A3 paper (approximately 11 x 17 inches). They provide a vehicle to capture and communicate knowledge across the development organization.  Reusable knowledge A3s written to capture knowledge  take a certain amount of effort to create, but they are worth the effort!

A3

These types of A3s are quite different from the A3s used by many Lean Manufacturing companies to manage a Kaizen used for tracking tasks to move from a current state to a future state.  A Knowledge A3 is less about doing things, and all about documenting important knowledge and learning.

For knowledge and ideas to be reused and improve the development cycle for the next project, ideas and knowledge must be documented, but more importantly, they must be easily found and reused.   The goal is to set up the knowledge pull within the organization. Therefore, the A3s must be put into a knowledge supermarket from which they can be pulled.   (In this case, “pull” is defined as retrieving and reusing knowledge as it is needed or per the demand of the next project).

It is important to take the time to ensure that Knowledge A3 is truly generalized, that it is from a trusted source, and that it is accessible.  These are three important characteristics of a well-functioning knowledge management system.  Toyota did this for many years by creating the “Know-How” database.  It was described in the book The Machine that Changed the World.   It is one example of how a Lean company (Toyota in this case) approached their development process by focusing on knowledge.   The “Know-How” database existed in paper form for decades before Toyota converted it to an electronic system.  Toyota had kept knowledge on everything from door handles to transmissions. The “Know-How” database represented the knowledge, engineering guidelines, and checklists that guided the design process to ensured quality.

Your Knowledge A3s will be focused on your own products, systems, and sub-systems.   The knowledge A3s work for IT systems and IT development just the same.  Knowledge A3s might be about a particular set of user needs or use models.  Alternately, the A3 might be about the architecture of the system itself, or about an important sub-system.   The goal is to document the knowledge so it can be pulled and reused each time a similar system or sub-system is developed.

For entrepreneurs working at a new start up, knowledge reuse is even more important in these cases.  Using prior knowledge to not reinvent the wheel for creating the business or the products certainly speeds up the time to market.

Lean design requires idea and knowledge sharing.

For Lean Development Excelence

Tim Schipper

Author of Innovative Lean Development.

Huthwaite Summit – 20th Anniversary

The Huthwaite Innovation Institute’s Annual Mackinac Island summit is in its 20th year.  The dates are August 13 through 15, 2013.  This unique gathering brings together a select group of top executives for two and a half days of networking and work group sessions designed to foster the exchange of ideas and innovations covering the top obstacles implementing  designs that are lean corporate wide. Executives will have the opportunity to further establish best practices for design through peer collaboration and executive education in a fun and relaxed environment.

At the end of the summit, you will know how to:

  • Make innovation a sustainable management process, rather than a random event
  • Integrate innovation into your existing continuous improvement initiatives
  • Measure whether you are on the right track early enough to make course corrections
  • Use innovation to find new market opportunitiesMackinac Island Sunset
  • Apply innovation to improve your day-to-day business operations.
  • Get all ‘stakeholders’ on board from Day One. . . and keep them on board
  • Systematically go outside your corporate boundaries to discover new ideas
  • Enable teams to innovate without creating chaos, delay, and low morale

Benefits of Attending:

Participation will enable the implementation of lean techniques for design within your organization.   Participants will hear powerful “lessons learned” from other companies and will have the opportunity to share their successes and obstacles. We will discuss the greatest challenges implementing and lean system, and how companies are addressing those issues.

Is your development team on the proper trajectory for success?

Development Trajectory …

Apollo_CSM_lunar_orbit

Trajectory is not a word that is used very often anymore.  When I was growing up, however, I recall that the word was frequently used with the Apollo missions to the moon.  I was 10 years old in 1969 when the first man stepped onto the moon.  One of the primary concerns was firing the rockets of the Apollo command module at the right time and for the correct duration to put it on the proper trajectory toward the moon.   The critical goal was to have the rocket carrying the astronauts leave the earth’s orbit and point it toward the moon with enough accuracy so that it could enter orbit around the moon.  This required a lot of mathematical calculations and a deep understanding of physics by the engineers and scientists.    Accuracy was of the utmost importance.    Additional course corrections could be made along the way, but the initial burn was the most important.

In development, the trajectory is often set early.  If it is set correctly, then the goal can be reached.   If the trajectory is set incorrectly, then the goal will never be reached.  The project must be directionaly correct from the start.   All factors and design elements have to be considered from the start.  These are difficult to anticipate because there can be many unknowns when development is started.

The proper development technique is to identify the knowledge gaps upfront that must be closed.  This end-in-view thinking helps to set the trajectory of the entire project.   The Lean Design Solution (Huthwaite) describes the techniques to set the proper trajectory of the project by exercising End-in-View thinking.

One technique that teams have used is to brainstorm as many knowledge gaps as possible at the start of the design.  Brainstorming alone, however, does not always properly uncover all of the gaps or set the team on the right course to find the correct solutions.  A more structured method is required.  The proper gaps must be uncovered to show the team what knowledge must be researched and documented.  Some knowledge gaps might identify new areas of research and discovery.  These are sensitive areas that require careful exploration.  The entire solution space of unexplored knowledge gaps must be explored.

The LEAN Design Solution describes methods to expose the gaps, and it provides a method to fully explore the solution space and close the gaps.  And Innovative LEAN Development (the book I co-authored with Mark Swets) tells how to rapidly close knowledge gaps and document the knowledge gained using rapid learning cycles.

As the team closes the knowledge gaps, the project trajectory is managed and can be effectively set to point the team in the proper direction.   Are you and your team setting yourselves up on the correct trajectory?
~Timothy Schipper