Tag Archives: lean

  • -

What do you know about speed 1/5? Boeing 737 Final Assembly

Tags : 

How long does it take to do the final assembly of a Boeing 737? Final assembly includes wings, tail, wheels, engines, interiors, wiring, cockpit controls and flight systems.

The Boeing 737 is assembled in one plant in Renton Washington near Seattle. Since implementing Lean thinking and continuous improvement monthly output of 737s from Boeing’s Renton plant has tripled:
1999  11
2005  21
2014  42
2017  47
2018  52

As of April 2015 the two 737 production lines produce 42 planes per month, or 2 planes per day. It takes 9 days from the time an empty shell arrives at the factory until a completed plane roles out the door ready to fly to the paint shop.

Interested in learning how to speed up your projects? Innovel offers Certified Scrum Master and Lean and Agile for Managers courses to show you how to speed up your IT, Marketing, and Development projects. Contact us for training and coaching in Lean, Agile and Scrum.

A timelapse of a Boeing 737 being assembled.


  • -

New ebook, Agile Advice

Tags : 

book coverMy colleague Mishkin Berteig started his Agile Advice blog in 2005 when we were both doing Agile coaching for teams at Capital One. His blog was one of my favorite Agile blogs, he was getting out the lessons we were learning and providing smart succinct advice. In many ways Mishkin’s blog was ahead of its time, offering sage advice to issues and situations that many people had yet to come across. Mishkin has taken his blog content, tuned it up and added additional interesting stories in his new ebook Agile Advice. You can check out the blog for many great ideas, while the ebook is a more convenient format for those looking to improve their coaching and Agile transition knowledge.


  • 1

Eli Goldratt, a brilliant contributor to making work and life better. 1947 – 2011

Tags : 

“I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?”

Dr. Eliyahu M. Goldratt 1947- 2011


Eli Goldratt When I first read Eli Goldratt’s book The Goal, it was in 2005. I had been using XP and Scrum for 3 years and understood the value of good process improvement ideas. I was stunned after reading it. Not only was the book fantastic, I was shocked: this book had been written in 1986?!?! I felt embarrassed that I had never known about these ideas. In 1986 I was still in engineering and these ideas were cutting edge at that time. Is Theory of Constraints taught in engineering schools 25 years years later? A search of goldrattschools.org reveals 9 affiliated universities, and google searches are not filled with education institutions teaching Theory of Constraints (TOC). It seems most people learn about Theory of Constraints through direct efforts of Goldratt’s various institutes, the Goal and subsequent books, and word of mouth. I have told many people about and given away copies of the Goal, creating numerous converts to Theory of Constraints thinking. Goldratt’s ideas provided many insights into systems thinking and process improvement. As a software development manager who had already transitioned from more traditional management to Scrum and Extreme programming, I found TOC provided another set of thinking tools to analyze a work system. These tools complimented Lean and Agile without reducing their value or conflicting with those ideas. For example Theory of Constraints provides a way to prioritize process changes found using Lean tools or impediments found by the team using Scrum. However the biggest change was that TOC made me think differently. It changed my perspective on systems, on software development and work in general. Like Lean thinking, TOC colors my thinking about any system and gives me greater insight into the natural properties of systems.

Ours and future generations are indebted to Goldratt’s ideas and his insights into people and systems. His ability to write about these ideas using non-technical stories was almost as important as the ideas themselves. His writing allowed many people to pickup his books and within a few hours understand the core concepts of Theory of Constraints. The appeal of TOC ideas caused them to look for ways to apply TOC to their work, while his easy and accessible style created powerful incentives for people to learn more.

I am truly sorry to hear that a genius such as Eli Goldratt has passed away at the relatively young age of 64. I am grateful to have been a student of his ideas and hope to carry on the work of spreading the ideas of TOC and its applications in software development and knowledge work.

From the Goldratt Schools website:

Dr. Eliyahu M. Goldratt spent his entire adult life fighting to show that it is possible to make this world a better place. We must have the honesty to see reality as it is, we must have the courage to challenge assumptions, and above all, we must use the gift of thinking. Having applied these principles to various management fields, he created the Theory of Constraints. His concepts and teachings have expanded beyond management and are being used in healthcare, education, counseling, government, agriculture and personal growth – to name a few fields using TOC. His legacy is invaluable. On June 11th, 2011 at noon, Eli Goldratt passed away at his home in Israel in company of his family and close friends.

The strength and passion of Eli allowed him to spend his last days sharing and delivering his latest insights and breakthroughs to a group of people who have committed to transfer this knowledge to the TOC Community during the upcoming Theory of Constraints International Certification Organization Conference in New York. It was Eli’s last wish to take TOC to the next level – truly standing on the shoulders of the Giant he is.

Robin Dymond


  • -

Lean Six Sigma: Are DMAIC Demons Possessing Lean?

Tags : 

Halloween is a few weeks away, and the strange world of the dead, undead, partially dead, or dead fashion is inhabiting the shopping malls. Over the last two years I’ve watched another kind of possession has happened in business thinking. Once the darling of Motorola, GE, Bank of America and others Six Sigma has been falling out of favor. Six Sigma’s DMAIC model, its emphasis on gathering statistical data and focus on elimination of variation has floundered in knowledge work. Knowledge work has at its heart, people. There is no machine stamping parts. In knowledge work, the work being done is continuously varying in size and complexity. The work of problem solving is done in people’s brains, and the effective flow of information in the work system controls errors. All of the variation in these complex adaptive systems means trying to eliminate variation is a zombie’s errand. Lean and the Toyota Production System are principles based. Many of the ideas in Lean can be applied to Knowledge Work. Ideas like Respect for people, Pull, Flow, Visual Management, Value Stream Mapping, Systems Thinking and Continuous improvement all make sense in Knowledge Work. These Lean and TPS ideas can be used with systems that adapt and change based on the variation inherent in the work.

Over the last few years Six Sigma consultants have started to re-brand themselves as Lean Six Sigma consultants. The adoption of Lean onto their business cards is partly a survival strategy. If Six Sigma’s not selling and Lean is, then let’s “do” Lean too. The problem is that Lean and TPS come from a very different perspective on work than Six Sigma. For example Six Sigma’s DMAIC process is:

  • Define the problem, the voice of the customer, and the project goals, specifically.
  • Measure key aspects of the current process and collect relevant data.
  • Analyze the data to investigate and verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered.
  • Improve or optimize the current process based upon data analysis using techniques such as design of experiments, poka yoke or mistake proofing, and standard work to create a new, future state process. Set up pilot runs to establish process capability.
  • Control the future state process to ensure that any deviations from target are corrected before they result in defects.

There are some major problems with the DMAIC approach when dealing with knowledge work:

  • Defining the problem with voice of the customer is great. However what if the customer can’t articulate what they want? Every software customer I have worked with did not have a functional crystal ball. They can often describe at a high level their needs, but they do not yet have enough information. The only certainty is that they won’t have enough information. Neither do developers.
  • The underlying assumption of Six Sigma is that the process under study is a repeatable process producing the same type of work product and subject to some statistically relevant variance. Measuring aspects of the process gives data to better understand where variation occurs. In Knowledge Work such as software development or marketing campaign creation the work is continuously varying so the measurements measure a complex adaptive system, not a repeatable process.
  • Analyzing the data gathered will provide some insights. Let’s say that data reveals a problem and a solution is found. Putting an improvement in place will definitely help. We may rarely do that type of work again. What happens when down the line a different problem occurs that we have never seen and do not have a measurement for?
  • How do we know we have the most correct process just from analyzing work in our current process? In Knowledge work, the work itself often impacts the process.

Six Sigma’s underlying assumptions fail to account for complex adaptive work systems that rely on people to do the problem solving and rely on information flow to do error correction. So why do people apply Six Sigma processes to knowledge work and what happens when they do? More on this later…. time to catch a plane.


  • -

Kangaroo boxing: Scrum vs. Kanban.

Tags : 

Software development has its trends and its innovations. The term Agile came about because people practicing different iterative workstyles decided to come together and develop a brand, Agile, that represents their common principles and values. Agile workstyles include Scrum, eXtreme Programming (XP), Crystal Clear, Feature Driven Development (FDD), and Dynamic Systems Development Method DSDM. Then people like Mary and Tom Poppendeick recognized that Agile software development could benefit from the ideas of the Toyota Production System, also called Lean for western implementations. Now some of the proponents of Lean, many of them from the Agile community, have been attacking Agile methods like Scrum, claiming that Lean is “better.” To me this doesn’t make sense. Agile and Lean ideas are complementary. Ideas from Lean come from manufacturing, so applying them to software development requires care and understanding of how software is different, and why. More importantly however, the conflict goes against the spirit of Agile, and does not do the software development community any good. It drives a wedge and a barrier where there should be none. It causes proponents of either camp to ignore or resist good ideas from the other. Primarily this conflict seems driven by personalities in the community who see personal gain and status with attacking another’s work. The idea that in a community of thinkers one can gain reputation by putting down other proven and legitimate ideas is false. Gaining reputation in a community of thinkers such as software development requires that you show leadership in new ideas AND in integrating new ideas with proven ideas already in place. The battle of Scrum vs. Kanban reminds me of kangaroo boxing… Richard Attenborough narrates…