Reading: The Secret Sauce of Success

Have you ever thought about what one habit ultra-successful people have in common? Sure you have! We look up to highly successful people as mentors and guides to the path of our own success. Everyone looks at them and studies their habits to learn the secret sauce’ of just exactly what creates their success.

Well, here is the answer: Every highly successful person will tell you their one secret to success ¦ they read. A lot!

Warren Buffett was once asked about the key to success. He pointed to a stack of nearby books and said, Read 500 pages like this every day. That’s how knowledge works. It builds up, like compound interest. All of you can do it, but I guarantee not many of you will do it. Buffett takes this habit to the extremeŠ ” Šhe reads between 600 and 1000 pages per day when he was beginning his investing career, and still devotes about 80 percent of each day to reading.

Other top business leaders and entrepreneurs who make reading a major part of their daily lifestyle:

¢ Bill Gates reads about 50 books per year, which breaks down to 1 per week
¢ Mark Cuban reads more than 3 hours every day
¢ Elon Musk is an avid reader, and when asked how he learned to build rockets, he said, I read books.
¢ Mark Zuckerberg resolved to read a book every 2 weeks throughout 2015
¢ Oprah Winfrey selects one of her favorite books every month for her Book Club members to read and discuss

A study of 1,200 wealthy people found that they all have reading as a pastime in common.

Successful people don’t just read anything. They are highly selective about what they read, opting to be educated over being entertained.

They believe that books are a gateway to learning and knowledge.

In fact, there is a notable difference between the reading habits of the wealthy and the not-so-wealthy. Successful people tend to choose educational books and publications over novels, tabloids, and magazines. And in particular, they obsess over biographies and autobiographies of other successful people for guidance and inspiration.

Start Reading Books Written By Paul Akers

Paul Akers is an entrepreneur and leader in creative and innovative business practices. As the founder and president of FastCap, a product development company specializing in woodworking tools and hardware for the professional builder. His intense curiosity on how things could be improved paved the way for him to become a prolific innovator. Today, Paul holds many US and international patents, and his company launches approximately 20-30 innovative products per year.

Paul’s core passion is helping people discover their full potential, and showing others how to implement Lean in their business and personal life. His passion for Lean has taken him around the world to over 65 countries to work and speak. He has devoted his life to teaching Lean concepts with passion and excitement. You can learn more about Paul on his website at PaulAkers.net

The following 3 books are a great way to get your reading discipline off to a great start! His 3 books below are easy to read, motivational, entertaining, and filled with practical examples.

The best part is that they are FREE from his website, if you want an electronic or audio version!!

   2 Second Lean

Can you make an improvement at work that saves 2 seconds from your day? Everyone can do that! That’s what makes “2 second lean” so much fun, and it engages everyone in the company in making improvements.

“There are plenty of workshops, executive manuals and textbooks on the market. I wanted to write a book that would make Lean accessible to everyone, from homemaker to executive. This is a real life journey that examines the astounding results Lean thinking can produce!”

Get the PDF, Kindle, or audio file here.

   Lean Health Book

Are you looking to get in shape, or live a healthier lifestyle? Paul will help you re-think your relationship with food and exercise, using the concepts of lean and waste. The results speak for themselves, as Paul has transformed his own life over the past couple years.

“Lean thinking can make a difference in your health if you think of it as a car. Do you think of your body as a Ferrari and treat it like a powerful and well designed machine? Or, do you treat your body like an old jalopy, lacking in power, efficiency and just getting down the road? Not surprisingly, most people find their machines low on the necessary fuel, oil and maintenance required by the machine to achieve the highest performance possible. Learn to take care of your body just like a high-performance Ferrari.”

Get the PDF, Kindle, or audio file here.

  Lean Travel

Does traveling cause you stress and headaches? For most people, it can cause just as much stress as what your vacation is trying to relieve. Paul is an avid traveler, and shares his advice and tips for making travel easy and efficient. Again, he ties everything back to lean concepts and the 8 forms of waste.

“Travel is one of the most inspiring and educational experiences we can have. For most, the true experience of global travel is elusive. For the ones who do experience travel, most miss out on the pure joy and enlightenment travel brings us. In this book, we learn to understand and experience travel the way it was intended, through the simplicity of Lean thinking.”

Get the PDF, Kindle, or audio file here.

The post Free Books from Paul Akers on 2 Second Lean, Health and Travel appeared first on 6sigma.

[contentblock id=35]

1. Joe Spooner said, August 21, 2006 @ 1:58 pm What are some of the agile development success stories Mary has seen in government or higher education?

I haven’t done a lot of work with governmental organizations and none with higher education. But I did have one great experience with a defense contractor. The group had a very interesting project going, but every month they had to report to the general in charge how they were doing on something like 63 process measurements. They found this frustrating and so did the general so they wanted to know how to improve their measurements. I asked what does the general really want you to accomplish in the end? Find that out, and then figure out how to constantly test your current capability to do it. Show your progress to the general at the beginning of every report, and you’ll get his attention. Some months later I learned that the team had established a single, high-level performance measure, and then they focused like a laser on making sure that the software improves that measure every month. The general follows the team’s progress with great interest, the team is completely engaged, and the program is considered an outstanding success.

2. Mishkin Berteig said, August 21, 2006 @ 2:25 pm Mary, based on your experience with lean environments and your experience with agile environments, what do you think is the most important improvement or change to be made to the Scrum methodology to make it more lean?

Scrum should not be considered a static methodology, it should follow its own advice (inspect and adapt) and evolve over time. One way to make sure this happens is to keep up with what Scrum’s inventor, Jeff Sutherland, is doing with it today. It is important that Scrum teams focus on the whole product, not just developing software. At Jeff’s company, this is accomplished by defining the end of a sprint as successful live deployment at multiple customers’ production sites. The whole development team is engaged not in making the product owner happy, but in getting all targeted customer sites to go live on time. This means sending out release candidates early and happily accepting and adapting to the surprises they uncover. It makes the customers’ users and support people as much a part of the team as the developers.

According to Jeff, ScrumMasters must be true leaders who help teams self-organize to meet commitments. The team must focus on and adapt to customer needs dynamically, as part of every sprint. Architecture must support incremental development. Disciplined development and deployment practices must be in place. Product managers must have an accurate, up-to-date assessment of what is possible, and may commit only to what can be done within the team’s proven capacity. Finally, senior management and company culture must be fully engaged in supporting this way of working.

3. Jeremy B said, August 21, 2006 @ 2:31 pm What is your favorite experience about agile and lean development to interest people?

Agile development is a good description of how I developed process control software in the early 1980’s. I worked as a junior member of a very experienced and competent engineering team that built new plants and put in processes to make roll-based products such as adhesive tape, magnetic tape, graphics products, anything you could make by spreading some sort of soup on a film. This organization’s job was to build new plants and design and install new equipment every job was completely different than anything that had ever been done before. Computer controls were just coming in at the time, and I was the new kid who knew how to program minicomputers. I learned how to do disciplined, adaptive development as I watched these experts design a new plant and its new equipment and get it in shape to make a completely new product. Although there was no talk about process, the organization could repeatedly and reliably design and install a top-notch new manufacturing line in about a year.

4. TheBizofKnowledge said, August 21, 2006 @ 3:09 pm In your opinion, what is the best way for a company to switch from plan-driven projects to an Agile/Lean approach? Is agile/lean the best environment for all projects, or are there some that might work better if handled in a more traditional way?

I don’t like the term plan-driven’ when it is used as an antonym for Agile, because Agile is as plan-driven’ as any other approach; I would use the term forecast-driven’ instead. Agile is feedback-driven, while non-agile approaches tend to be driven by forecasts of the future. In domains where these forecasts are likely to be accurate, you can assume that the forecast is fact and devise a plan based on that assumption. Just remember when variances occur that they are as likely to be caused by faulty assumptions as faulty execution.

When a forecast is a mere guess, it is far better to use an approach which adapts to the future as it unfolds. In manufacturing feed-back-driven (pull) approaches produce better results than forecast-driven (push) approaches in almost all cases. I would speculate that the same is true of development, although I don’t believe that any single approach can fit all situations.

To return to your first question, the first step in moving from forecast-driven projects to feedback-driven agile/lean methods is to change the measurements. The book Rebirth of American Industry by William Waddell and Norman Bodek makes a good case that the measurements imposed by traditional cost-accounting methods are the biggest impediment to the successful implementation of lean manufacturing. Similarly, I believe that the measurements imposed by traditional project management methods are the biggest impediment to the successful implementation of lean development. In particular, instead of measuring variation from plan, we need to start measuring the delivery of realized business value.

If a company wants to move from a forecast-driven development to a feedback-driven development, it needs to shorten the cycle time from customer request to software delivery, or from concept to cash. The shorter your delivery cycle time, the more responsive you can be to feedback. Queuing theory says that short delivery cycle times depend on having very short queues of work-in-process, so a good approach for switching to agile is to take a hard look at how much partially done work you have in your system.

Start by looking for churn (rework): if you have test-and-fix churn, you are testing too late. If you have requirements churn, you are specifying requirements too soon. Next look at the defect list: test-driven development finds and fixes defects before they need to go on a list. Finally, look queues of work between departments: a cross-functional team can develop an increment of value from idea to deployment without using an inter-departmental list or queue.

5. Carlos Miranda said, August 21, 2006 @ 3:19 pm Which are the differences between your two books on Lean Software Development?

Our first book, Lean Software Development, is aimed at people who do not understand why Agile development is a good approach. It provides the underlying justification for rapid, incremental development. The second book, Implementing Lean Software Development, makes the assumption that the reader has bought-into agile development, and wants to figure out what to do next.

The second book is filled with things we have learned over the last few years: including answers to questions we have often heard and (anonymous) stories of enlightening situations that we have encountered. It delves more deeply into areas we have found to be increasingly important, including:

1. A Focus on the Whole Product 2. Test-driven Development 3. Respect for People

6. Horst Franzke said, August 22, 2006 @ 4:10 am I see teams entering the Lean software arena through a specific set of practices (e.g. XP), which often help them attack their most obvious problems. BUT at the same time I see many teams miss the underlying Principles, which would help them to really grow and improve in the long run. What would be your approach to help such a team with lean practices to adopt the underlying principles? Thanks!

The first thing I would do is ask these questions:

1. Is the team focused on delivering increments of real value to end customers and does everyone understand what that really means? 2. Is the team a Whole Team composed of everyone necessary to deliver value to the ultimate customer? 3. Does the team reliably and repeatedly delivers on its promises?

When you can answer yes’ to these three questions, I’ll bet you won’t feel the team is missing underlying principles. If your answer is no’, then the first order of business is to change it to yes’. But how do you do that? I observe that when teams miss the mark in the areas I just mentioned, there is often a leadership vacuum. Take a look at the team and see if it has both technical and marketing leadership. I believe that teams need a leader who understands and cares deeply about the customers and their problems. They also need a leader who understands and cares deeply about the technical integrity of the product. This leadership may reside in one or two people, or in small teams it may be distributed among several people. But teams which lack market and technical leadership tend to produce mediocre results.

7. Steve Hebert said, August 22, 2006 @ 2:37 pm In addition to the lean tools that programmers use, how do you influence lean processes outside the group (minimizing unchecked code downstream in QA and helping upstream specs arrive at the last responsible moment)? Also, what tools do you see that exist to help manage this type of process (i.e. seeing how many turns features take between development and QA, allowing all team members to triage their own lists, handle gating of large functions (release an item to QA when all needed components have been completed). Thank you

Your question seems to indicate that separate organizations exist to create specs and check code. I would recommend that these responsibilities should not reside in separate departments, but specialists in these areas should be members of a Whole Team everyone necessary to deliver value to the ultimate customer. An increment of customer value should go from specification to delivery in a very short time without spending time in interdepartmental queues. I would not measure turns of features between development and QA there should not be any such thing. In lean manufacturing, the job of QA is to mistake-proof processes so that it is impossible to produce defective material.

In lean software development, the job of QA is to create a test-driven environment that makes defects virtually impossible. Thus QA precedes development, it does not follow it. The idea is to go from feature request to production deployment in a very short cycle time. Jeff Sutherland’s company, PatientKeeper, has three cycle times: They deliver any maintenance fix they choose to implement in a week. They deliver any new feature they choose to implement in a month. They deliver any new application they choose to implement in three months. By deliver’ I mean they go live into production at customer sites customers who are using their software to store medical records. Each year for the last three years, the company has gone live with about 45 releases a year, never missing a deadline. PatientKeeper uses one tool to accomplish this fete it is a tool that lists in detail what remains to be done for every pending release, and how long that work is expected to take. The development team is never loaded beyond its capacity to deliver, and the management team at the highest level of the company adjusts release expectations every week to be sure that teams can meet their deadlines.

8. Vivian said, August 24, 2006 @ 3:11 am I am planning to launch Lean Concepts and Tools for process improvements. I would like to first introduce Lean thinking and Concepts and some time down the line introduce basic tools. My company is a part of the Outsourcing Industry. Could you show me a roadmap that’ll make the launch successful?

There is no roadmap that will guarantee lean success, but we do have a roadmap at the end of our new book that might help get you started in the right direction:

1. Begin where you are: How do you create value and make a profit?

2. Find your biggest constraint: What is the biggest problem limiting your ability to create value and make a profit?

3. Envision your biggest threat: What is the biggest threat to your ability to continue creating value and making a profit over the long term?

4. Evaluate your culture: Establish and reinforce a culture of deep respect for front line workers. Remove barriers that get in the way of pride in workmanship.

5. Train: Train team leads, supervisors and managers how to lead, how to teach, and how to help workers use a disciplined approach to improving work processes.

6. Solve the Biggest Problem: Turn the biggest constraint over to work teams. Expect many quick experiments that will eventually uncover a path to a solution.

7. Remove Accommodations: Uncover the rules that made it possible to live with the constraint. Decide what the new rules should be.

8. Measure: See if end-to-end cycle time, true profitability and real customer satisfaction have improved.

9. Implement: Adopt changes supported by results.

10. Repeat the Cycle: With the biggest problem addressed, something else will become your biggest problem. Find it and repeat the cycle.

9. Jon VanSweden said, August 24, 2006 @ 5:34 am Mary, I am looking to benchmark a company that has applied Hiejunka principles within the office. Have you applied this lean tool in your organization?

An office organization is very different than a development organization, and I focus on lean in development, so I would not be able to recommend a company for you to benchmark. Heijunka in an operating environment means producing at takt time. In a development organization, heijunka means establishing a cadence that keeps development moving forward at an even pace. In software development, the cadence is established through regular, short iterations and regular, closely spaced releases. Just as in bicycling, a steady, relatively fast cadence optimized for your situation is the best way to sustain high performance over the long term.

10. psabilla said, August 25, 2006 @ 4:58 am I’d love to see examples (and/or) suggestions of how to implement the following to software organizations: 1) Kanban, 2) 5S, 3) Visual Workplace, 4) The Big Room (Product Management, Development, QA, etc¦) ” how to best plan and coordinate between all stakeholders, 5) SMED, 6) 5 Why’s, 7) TPM. This is an Epic-sized question, I know, but I think sharing your knowledge will help all of us tremendously. Thanks so much!

An epic-sized question indeed! I’ll do just a brief comment on each one, and then refer you to my most recent book, Implementing Lean Software Development: From Concept to Cash, for more on some of them.

1. Kanban. The Kanban of Software development is the index card. Stories are written on cards, estimated and selected at the iteration planning meeting, posted in the team room, updated when the story is being worked on and when it is done.

2. 5S’s. Apply the 5s’s to the server which stores the code and associated documentation, to desktop environments used by more than one person, and to the code base. We have examples in our new book.

3. Visual Workspace. There are three aspects to a visual workspace the Kanban card (index card) which tells people what needs ot be done, the Andon, or signal that something is wrong (eg. lighting up a red light when the build breaks), and big visible charts which tell everyone how things are going. We also have a section on this in our book.

4. The Big Room, or Obeya. Take a look at the video 21st Century Jet (KTCS, Seattle) and you will see good examples of the Big Room in action during the development of the Boeing 777 in the 1990’s. This isn’t a new idea, but it certainly is a good one.

5. SMED, or Single Minute Set-up. The time it takes to test and deploy a release is the set-up time of software development. Many companies take so long to test software that releases are very far apart, and every effort is made to stuff as much as possible into each big-batch release. Some companies release to production several times a day (anti-virus software comes to mind) they have SMED figured out.

6. 5 Why’s. Root Cause Analysis for any problem is a fundamental skill that all teams need to learn. First we have to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list. Only then can we start using the 5 Why’s to discover the root cause of the remaining problems that occur.

7. TPM or Total Preventative Maintenance. In software development, we call this refactoring. We keep on improving the design of the code base to keep it healthy and prevent it from calcifying and becoming a jungle that can no longer be maintained. Legacy code is code that has not had regular TPM.

11. Mike Griffiths said, August 25, 2006 @ 2:25 pm When comparing lean manufacturing techniques to software engineering. Some authors map Toyota’s Set Based Concurrent Engineering to practices such as supplying multiple available time-slots options for a meeting, yet the manufacturing process is really based on parallel development and then survival of the fittest solution. This would be akin to having several developers or teams of developers creating the same components and then selecting the best version. Have you seen SW companies follow a parallel development approach and aggressive pruning of less suitable solutions? Also, what guidelines (circumstances, batch sizes, etc) would you give for concurrent engineering in SW project?

The most important time to evaluate multiple solutions is when an irreversible decision that is critical to the success of the system must be made. For example: Which language should we use? Which middleware will we standardize on? Which database will we go with? How do we structure the architecture to support the response time we need? How will we organize the main flow of the user interface? And so on. It is a good strategy to make these tough and critical decisions as late as possible, and I have seen companies develop multiple solutions in all of these areas when the decision was critical to success.

Note that developing options does not mean setting up separate teams to compete; usually it entails creating objects that are a bit more general, and maintaining multiple build-time options. For example, it is fairly easy for a code base to support multiple databases, user interaction strategies, and even middleware, with the selection made at build time. There certainly are critical choices that can’t wait until build time: language, security strategy and the core architectural strategy come to mind. When these types of choices are critical to the success of the system, it can be a good idea to thoroughly explore several approaches by actually developing and testing critical capabilities using each alternative. However, for most parts of the code and in most (but not all) domains, the best way to maintain options is to minimize the number of irreversible decisions that are necessary.

Early releases of software should not preclude future changes. Instead early releases should be as simple as possible and protected with tests, so that the code is easy to change later. The use of change-tolerant coding techniques is the quite often the best way to maintain options in software development this allows exploration of the design space sequentially, as the problem emerges. I find that embedded software and games are domains that are particularly amenable to set-based design, that is, the exploration of multiple solutions during development. This is because these types of software generally do not change once they are released, so the decisions made during development are, basically, irreversible.

12. Deborah Hartmann said, August 27, 2006 @ 8:34 am I’ve heard vaguely, several times, of something that’s beyond Agile and referred to as Lean, though I don’t really know if it is. Called a flow process, it seems to describe a short-cycle-time software production line, in which there is no backlog, or maybe just a short one. I was referred to your book but didn’t find it. I must admit, it sounds like lazy Agile to me – just do whatever comes in, don’t bother setting expectations. Any idea what I’m talking about here, where it comes from? Is this a photocopied too many times version of some valid approach?

Developing Software in a short cycle time from concept to cash is covered in some detail in our new book, Implementing Lean Software Development (release date August 29th, 2006.) Short cycle time development is hardly lazy! It is quite a challenge to be able to fill a request or develop a new feature set just as soon as the need is recognized. Short cycle time expectations are very demanding: for example, when a new virus threat is discovered, a security response team is expected to have software to defeat the threat ready to deploy within hours.

Just about every software development organization I know of has a list of work to do that is far longer than it can hope to accomplish in what customers would consider a reasonable amount of time. And rarely do these organizations have the luxury of turning off the spigot of requests coming in. So the waiting list of stuff to do gets longer and longer, and the development organization looks to be increasingly unresponsive.

Agile development solves this problem by having someone prioritize the list and then having the development team select from the top of the list the amount of work it can reasonably expect to accomplish within an iteration. But look at this practice from the point of view of the people who have their requests lower down on the list. They have no idea when their request might get filled, and in practice, most items lower down on the list will probably never get done. In a lean environment, the idea is to keep the list of work to be done as short as possible, by dealing with requests honestly at the onset and by not accepting work beyond the capacity of the team to deliver.

In the health care industry, some experiments were done with waiting lists at doctor’s offices. One clinic near us used a combination of overtime and limiting new patients to gradually shorten the typical waiting time for a doctor’s appointment from 60 days to 2 days. What they found was that there was no difference in the types of cases the doctors handled on a daily basis except for the fact that patients had only been waiting a day or two, rather than a month or two, to see the doctor. The 60 day waiting lists served no useful purpose at all.

Similarly in software development, long queues of work often serve no useful purpose and worse, they give the wrong message to customers about our intent to deal with their problems. Such lists should be pared down from years worth of work to perhaps a couple iterations worth of work. Agile development gives us visibility into the capacity of a team to deliver, lean development suggests that we do not queue up work beyond that capacity.

The post Book Review: Implementing Lean Software Development appeared first on 6sigma.

[contentblock id=35]

The 33 Strategies of War is rote full of long, drawn-out historical and philosophical dialogue, that purports to support his 33 strategy thesis. Some of the stories are interesting; most are long and boring, but actually descriptive and supportive of the thesis. All in all, the book was instructive, descriptive, and helpful. I’ve learned the games that people and groups play. Strategy, indeed, can be learned; this book is a good step towards that.

If I were to buy this book, I would buy a used copy from Amazon or somewhere else. It’s not a bad book to read, just boring, but instructive in some ways. People can be very vicious in strategy and war. Reading this book has helped me see the world a little differently.

The post The 33 Strategies of War Book Review by Robert Greene appeared first on 6sigma.

[contentblock id=35]

So,

• Buyout: The Insider’s Guide to Buying Your Own Company

This was an interesting book, written by a long-time practitioner in the private equity industry. It was an easy read and provided some good, in-the-trenches stories and tips.

• Venture Capital and Private Equity: A Casebook

This one was also very interesting to read. It contains several cases that highlight the VC and PE industry. It’s quite theoretical, and not as practical as Buyout : The Insider’s Guide to Buying Your Own Company but it’s still interesting and definitely a very good reference book. Here is the book’s description on Amazon:

Book Description: Over the past twenty years, the private equity industry has undergone tremendous growth and sweeping changes. With the growth of private equity investing, it is imperative that financial professionals fully understand this complex subject. The cases and notes in this updated edition are designed to provide you with a better understanding of the history of the private equity industry’s development and the workings of the industry today. Divided into four modules, the first examines how private equity funds are raised and structured; the second considers the interactions between private equity investors and the entrepreneurs that they finance; the third discusses the process through which private equity investors exit their investments; and the last considers the future of the private equity industry.

From the Back Cover: Why have private equity funds experienced such tremendous cycles of boom and bust? How have these funds created so much value? Can we expect this kind of growth in other countries and other types of investments? These are just a few of the exciting and important questions you’ll explore in this new and updated collection of real-world venture capital and private equity cases. Now thoroughly revised to reflect the new realities in today’s venture capital and private equity markets, Lerner, Hardymon, and Leamon’s Third Edition addresses such timely issues as troubled portfolio companies, markedly smaller funds, and ongoing attempts to address the problematic practices of the late 1990s. The cases take you through each step in the venture capital/private equity process, including:

• Raising and structuring private equity funds
• Investing in, monitoring of, and adding value to companies
• Exiting investments and returning capital to the private equity group’s investors
• Adapting the private equity model in other settings, such as corporate and community development venture funds

About the Authors: Josh Lerner, the Jacob H. Schiff Professor of Investment Banking at the Harvard Business School, is one of the best-known authorities on venture capital. Both his academic and practical activities focus on the structure and workings of these funds. His mix of practical and academic perspectives is at the heart of this book. Felda Hardymon is a Professor of Management Practice at Harvard Business School and a partner since 1981 at Bessemer Venture Partners, a leading venture capital firm. Ann Leamon, after co-founding the Center for Case Development at Harvard Business School, now serves as Senior Research Associate dedicated to the Venture Capital & Private Equity class. She came to Harvard after a decade of senior analytical positions in operating companies.

I recommend both of these books for your reference library, if you’re an entrepreneur or an aspiring buyout person, or are just interested in business.

The post Book Review: Venture Capital and Private Equity a Casebook appeared first on 6sigma.

[contentblock id=35]

My earlier post titled, Good Complexity, Bad Complexity, I discuss a few case studies where produce and process complexity can be good, and where it can be bad. One of the areas in which a balance needs to be had between a rich feature set and low maintentance and manfucting overhead is in how we design our products.

On the one hand, if you have offer too many features in your product, it can lead to featuritis, which results in very unhappy customers, high maintenance and manufacturing costs, and eventually a slowly-dying and eventually dead product. On the other hand, if you have a product that has a feature set that doesn’t satisfy, yet has very low manufacturing and maintenance costs, that product, too, will eventually die. What we need is balance.

The Product Design determines ~75% of the maintenance and manufacturing costs of your product, whether it be a consumer packaged good, a software product, a widget, or any physical or virtual product — there’s going to be some maintenance and manfucturing costs involved. The way you design it will determine the costs on maintaining it and building it. The key, then, is to design quality in the manufacturing, and also to take advantage of some very basic industrial engineering tenets, simplicity principles, and here they are:

Emphasize Commonality

1. Modularity: Group like-functional elements in logical and seperate assemblies and sub-assemblies that share common elements. In software, we call this a base class that one can instantiate into something more specific. For example, a base class could be a car, made of metal and plastic; one could then instantiate that class and inherit the common pieces (metal, plastic, etc.) but instantiate it into a car with specific attributes such as color, shape, or engine type. The same approach can be taken with other product types too — in healthcare, an health insurance type can inherit common items from a more generic health insurance type — it’s an instantiated version of the parent insurance type. You get the point.
2. Platforms: A platform is any unit — module, set of modules — that serves as a base for multiple end products. This notion of Platform is extending the Modularity concept a little bit, and making it into a family of modular pieces with different functional goals. BUT, multiple end products can use their services, tasks, and reusability in multiple offerings. For example, a car maker can collapse several designs into just a few, build common manufacturing lines that are shareable between multiple car types.

A focus on Commonality leads to the following benefits:

• Improved efficiency through sharing of common processes and parts.
• Reduced lead-time, resulting in quicker time-to-market.
• Reduced working capital investments (and reduced intellectual capital requirements).
• Defect reduction.
• Flexibility in operations.
• Better use of resources.

Once commonality is achieved, the goal, then, is to focus on differences — in differentiation of the product (the instantiation piece). If your offerings are 90% similar, then you can better focus on the 10% that will add value in differentiation or customization for the customer.

Reuse & Recycling

Once you have a base class or platform, then creating new products would allow you to determine the “backwards compatibility” of the new product — that is, reusing the current manufacturing lines, parts, code to create the new product. The design question, then, is spent determining the customization and differentiation of the new product from the family of products. Code reuse; manufacturing reuse; and, service reuse — helps to reduce dramatically the time-to-market of the new product and costs.

Design for Manufacture and Assembly

This is basic engineering stuff, but one that hasn’t really made it into the mainstream yet.

1. Design for Assembly: Design teams considers the parts involved and attempts to reduce it through consolidation of parts or the elimination thereof. Does part x need to be seperate or part of assembly x? Questions like this helps to simplify design at the outset.
2. Design for Manufacture: This step investigates process and assembly issues and attempts to optimize parts design. Material or hardware is selected at this step and tooling corrections are made.
3. Design for Service: This part involves designing products for efficient maintenance and repair and upgrades. It establishes a disassembly sequence to service an item, identified items that must be discarded or replaced for specific service, tasks, assesses the degree of difficulty when servicing specific items, and generates a reassembly sequence and time estimate.
4. Design for Environment: This step helps to quantify a design in terms of cost and environmental impact, ensuring that products can be disposed of responsibly after use. There might be a ROI analysis on financial returns, costs, and environmental impact.

Inmates are Running The Asylum

In Cooper’s book, The Inmates Are Running the Asylum, he points correctly that products — both software and hard-goods — are over-complicated and are truly not making our life any easier. Most products wreak of featuritis or are laden with much non-value added complexity. Let’s get back to making life easier by producing better, customer-focused products. Let’s produce products that are simple, yet value-adding; elegant, yet pragmatic.

The post Book Review: The Inmates are Running the Asylum appeared first on 6sigma.

[contentblock id=35]

Patrick Lencioni presents the following model as the The Five Dysfunctions of a Team:

Below is his explanation for each piece of the model:

• Dysfunction #1: Absence of Trust — This occurs when team members are reluctant to be vulnerable with one another and are unwilling toadmit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible.
• Dysfunction #2: Fear of Conflict — Teams that are lacking on trust are incapable of engaging in unfiltered, passionate debate about key issues, causing situations where team conflict can easily turn into veiled discussions and back channel comments. In a work setting where team members do not openly air their opinions, inferior decisions are the result.
• Dysfunction #3: Lack of Commitment — Without conflict, it is difficult for team members to commit to decisions, creating an environment where ambiguity prevails. Lack of direction and commitment can make employees, particularly star employees, disgruntled.
• Dysfunction #4: Avoidance of Accountability — When teams don’t commit to a clear plan of action, even the most focused and driven individuals hesitate to call their peers on actions and behaviors that may seem counterproductive to the overall good of the team.
• Dysfunction #5: Inattention to Results — Team members naturally tend to put their own needs (ego, career development, recognition, etc.) ahead of the collective goals of the team when individuals aren’t held accountable. If a team has lost sight of the need for achievement, the business ultimately suffers.

Chime-in Comes Before Buy-in

One critical piece that relates to Change Leadership, which I’m very interested in, is the fact that before agents buy-in into an idea or concept or new way of doing things, people must first have the chance to weigh-in or chime-in.  After people are sincerely listened-to and heard, then buy-in can happen, whether or not the agents agree with the idea or are never initially persuaded.  This is a simple, yet powerful principle that often is not considered in most change management activities.  Without chime-in, agents resist to the change and change initiatives will most likely not get the momentum needed for wholesale adoption.

Conclusion

All in all, I have learned much from The Five Dysfunctions of a Team.  Leadership is an area I’m very, very interested in and wish to gain more experience in, and am actively trying to improve on.  I’m grateful for the experiences I’ve had so far that have helped me to learn more about Leadership and, in some some small ways, have helped me become a better leader.  Books like this continue to help me learn more of something I plan to always continue to learn more about and will always actively try to be better at.

The post Book Review: The Five Dysfunctions of a Team appeared first on 6sigma.

[contentblock id=35]

The Toyota Mindset was written by Yoshihito Wakamatsu who worked directly under Taiichi Ohno. The contents of this book is a documentation of his interactions with Taiichi Ohno – what he said, how he said it, and the “why” behind many of the well-known methods in the Toyota Production System.

His book is organized into 10 chapters, each of which he calls “Commandments”, claiming that Taiichi Ohno lived by 10 main ideas and makes a caveat that the word “commandment” are the author’s, not Taiichi Ohno’s.

Below are the 10 main ideas Wakamatsu claims Taiichi Ohno lived by:

1. Wastes hide, so start by disclosing all of your mistakes
2. Discover the truth beyond your understanding
3. Increasing production while limiting the number of workers is the only way to gain true success
4. Act on problems right away and do not procastinate
5. Don’t feel satisfied by saying “I finished the job”; go beyond that and say  “I can do more”
6. Add “Appropriate Timing” to “Appropriate Method” in problem solving
7. Believe in “I can” and question “I can’t”
8. The key to achieving progress is to never give up
9. Don’t do work at an average pace; the shortest way is always the easiest
10. Change yourself first, if you want to change someone else

Rather than attempt to give a summary of each of the chapters in one post, I’ll dedicate a post to each of the chapters in the Toyota Mindset. Expect those in the next several weeks.

The book is available on Amazon and the retail price is $34.99 and is currently in stock.

The post The Toyota Mindset Book Review and Thoughts on Taiichi Ohno appeared first on 6sigma.

[contentblock id=35]

Here’s the product description found on Amazon:

Written by the prominent consulting firm, Total Systems Development, Inc. (TSD), Lean Manufacturing: A Plant Floor Guide is a complete inventory of the elements needed for successful implementation. It provides an overview and a specific rationale for your initiative. It is an easy-to-digest reference to aspects of lean that you may not have known about. It’s a virtual toolbox of information that can be readily put to use on the plant floor.

Internationally renowned editors John Allen, Charles Robinson, and David Stewart take readers on a comprehensive, ‘street-level’ journey through lean implementation, from the seven wastes and flow processes to developing a business case, using lean tools, and applying readers’ newfound knowledge at greenfield and brownfield sites. Specific chapters on mapping the value stream, policy deployment, the five-phase implementation process, and problem-solving crystallize concepts with a pragmatic treatment. In addition, the brownfield implementation chapter is a must.

Here are the Chapters Sections:

1. Flow
2. Quality Feedback
3. Lean Measurements and Their Use
4. Mapping the Value Stream
5. Business Case Development
6. Change Management and Lean Implementation
7. The Five Phase Implementation Process
8. Creating a Lean Human Resource System
9. Policy Deployment
10. Work Groups
11. Visual Factory
12. Error Proofing
13. Standardized Work
14. Quick Changeover
15. Total Productive Maintenance
16. Problem Solving
17. Pull Systems
18. Lean Applications

All in all, I recommend this book as a great reference guide.

The post Lean Manufacturing Plant Floor Guide Book Review appeared first on 6sigma.

[contentblock id=35]

Here are a few reviews from Amazon:

Michael Greif has written a book on lean principles long before the MIT study resulted in “The Machine the Changed the World”.

The foundation of lean is generally agreed to be the 5Ss, kaizen, and visual communication. This book, while focused on VC, does adequately cover the others. Consider this… the book was written in the late 80’s, when Lean Manufacturing as a term had not yet been coined.

And now, the review… this is an excellent study on visual communication. Although limited in scope (most practical examples were of western European factories), it is a study that should not be limited to factories; rather, one that has application in many aspects of daily life.

Practical examples, diagrams, drawings, and checklists abound. Definitely user-friendly, and as the subject matter demands, visually communicative.

The post Book Review: The Visual Factory appeared first on 6sigma.

[contentblock id=35]

Here is the description found on the book cover:

In this groundbreaking book, Bill Price and David Jaffe offer a new, game-changing approach, showing how managers are taking the wrong path and are using the wrong metrics to measure customer service. Customer service, they assert, is only needed when a company does something wrong, eliminating the need for service is the best way to satisfy customers. To be successful, companies need to treat service as a data point of dysfunction and figure what they need to do to eliminate the demand. The Best Service Is No Service outlines these seven principles to deliver the best service that ultimately leads to no service:

• Eliminate dumb contacts
• Create engaging self-service
• Be proactive
• Make it easy to contact your company
• Own the actions across the company
• Deliver great service experiences
• Listen and act

David Jaffe’s draws much from his experience at Amazon.com Customer Service. His approach to customer service is based on many principles of Lean Thinking – specifically, Lean for Services. In sum, his approach can be summarized as follows:

A customer service contact is a symptom that something went wrong. The common approach to customer service is to optimize customer service – but, most people don’t want to contact customer service – the customer would rather not call customer service.

So, a better approach is to identify root causes of the contacts, put in place countermeasure, and eliminate the contact from ever happening.

The result: happier customers.

Below are a few reviews on the The Best Service is no Service:

A 5 Star Review:

If you believe, as I do, that earning the trust of your customers is the most direct route to long-term success for a business, then this is the book for you. This is probably the single best “how to” book on earning customer trust that I’ve ever read – and I have read most of them, and written several of them myself, with my co-author and business partner Martha Rogers (our latest and greatest: Rules to Break and Laws to FollowRules to Break and Laws to Follow: How Your Business Can Beat the Crisis of Short-Termism (Microsoft Executive Leadership Series)).

So congratulations to Bill Price and David Jaffe for such a sweeping, carefully delineated guidebook for business people just trying to do the right thing for customers. Jaffe is a customer experience consultant operating out of Australia, and Price is the ex-VP of Global Customer Service for Amazon, which says a lot about their perspective, because Amazon (as everyone reading this review should know) is one of the world’s true icons of great customer service. In the game of business, in other words, Price is not just a good coach, but a veteran player with a winning record.

Price and Jaffe concentrate primarily on how best to operate call centers, interactive voice response (IVR) units, Web sites, and other mechanisms for facilitating interactions with customers. The guiding principle for all customer interactions should be to reassure customers, empower them, and serve them well. The final objective, of course, is to ensure that customers find it as easy as possible to buy from you. But, as the authors persuasively demonstrate, no one is going to buy from you if they don’t trust you and have confidence in your service. And customers will only develop that trust if they judge that their interactions with you were efficient and customer-oriented.

Now I judge the merit of a business book in terms of how many comments I’ve underlined or highlighted, and how many page corners I’ve turned down during the course of reading it. By these criteria, The Best Service is No Service earns five stars from me.

For instance, I LOVE the “bad examples” that permeate the book. They’re so much fun to read, and it’s such a gas just chuckling at how stupid so many businesses can be in real life. The bank that automatically routes calls from its best customers to sales associates, forcing them to sit through new product pitches before they have access to the simplest IVR tasks like transferring money, for instance, while “ordinary” customers get to breeze through the IVR and do what they want quickly and efficiently (p. 71), or the IT company that, in an amateurish effort to be totally honest with customers, offered them (kid you not) 30,000 phone numbers to choose from worldwide (p. 134).

But the real heart of the book, and its true benefit for the reader, is its numerous checklists of things to do and not to do when operating an interaction center. At page 155, for example, the authors talk about providing the right choices for customers at every point, including (among other things):

• At the web site, phone numbers on every page, “talk to someone” or “chat” buttons, and “contact us” buttons that make it easy to send emails, stating how quickly they will be replied to
• For phone IVR menus or trees, Web site alternatives clearly mentioned, options to leave a number for call back, ability to hit 0 at any point to reach an operator
• Emails that go out with a phone number provided, along with links to the pages on the site that actually help to explain the issue
• Branch operations that have phones for calling the contact center directly, self-service desks for information, and Web PCs for direct self-service online
• Or consider his list of simple usability criteria (p. 91):
• Short menus on IVRs, just to make selection easy
• Consistency across IVRs and Web sites, allowing customers to know where things are and make their selections more easily
• Correct uses of silence on IVRs and white space on Web sites, so customers don’t always feel crowded or rushed
• Multiple support levels for the user, meaning that IVRs, for instance, should kick into a more detailed level when the user has a problem, and Web sites should be designed to help users recover from mistakes or problems
• Standard navigation features, meaning ability to repeat IVR menus at any point or drop bread crumbs during your Web search.

There really wasn’t much I didn’t like about this book. I wish they had been able to name more of the companies they singled out as examples (most of the bad examples don’t actually name the companies involved). And I suppose in some places the authors could have got to their point faster. They’re not the most economical writers, in their use of words. But these are very minor drawbacks, as I still found myself drawn in to the ongoing story they tell, and the very smart and succinct lessons they convey.

The fact is that interacting with masses of customers, individually, is a complicated and difficult business service that most companies have only begun wrestling with in the last decade or so, because the Worldwide Web has finally forced them to. There are a handful of businesses that did a sterling job – prior to the Web’s arrival – of using their call centers to inspire confidence and trust in their customers (USAA, for example, cited at p. 139). But for the vast majority of companies, prior to the rise of the Web, call centers were mostly treated as just one more cost of doing business.

“Customer interaction,” in other words, is now one of the dominant forms of “service” offered by most companies, but it is still a brand new discipline for most business people, with lots of unknown complications and unappreciated benefits. So if you want to better understand the implications of managing the customer experience when it comes to your own company and your own customers, then this book by Price and Jaffe is far and away the best, most comprehensive and practical education you can buy today.

A 5 Star Review:

I loved this book. It is well organized and written. It starts out with a diagram that represents a picture of how the best customer service is no (or little) customer service. And then it uses eight chapters of text to explain why the best service is no (or little) service. Each chapter ends with a good summary of what was covered in the chapter. And after each chapter summary there is a list of survey questions that help the reader apply what they have read to their real-world situation. Very well done!

The book also includes wonderful appendix material: a Best Service Survey, a glossary and a blibliography. All in all, this book redefines traditional notions of what a small business needs to do to be successful. By reading this book you will be reminded that good customer service is critical to the success of small business. However, there is no need (nor is it ideal) to over supply customer service. Too much customer service can negatively impact on a company’s profit margin because of the extra cost of payroll expense needed. And too much customer service can also be an opportunity to hurt customer relations (and relationships) rather than improve them.

The ultimate message included in this book is that small business will be most successful if they only provide customer service that is essential to doing business. Too much is not good and too little is likewise not good. Just keep the customers happy while keeping yourself happy and your business will be successful. 5 stars!

PS. The author has provided Search Inside material to Amazon that includes the Table of Contents for this book. I think the chapter titles explain a lot of what is covered in this book. Read those chapter titles along with my review to get the most out of it.

Here’s a Video of Bill Price answering some questions regarding his book:

The post Book Review: The Best Service is No Service appeared first on 6sigma.

[contentblock id=35]

This post is my review of the book.

Leadership, Not Just Dentistry

Dr. Sami Bahri is a dentist, with a practice in Florida. His history goes back to the early 90’s where he quickly became frustrated with the current state of dental practice – for him, it seemed inefficient and patients deserved better. He quickly read all he could on the current management fads at the time, then in 1996, while listening to Lean Thinking on tape, he received the answers he needed to transform his dental practice into one that encouraged and supported flow and enabled him to create a better patient experience [1. source: kaizensensei.org/medical.html].

In his words,

“When the patient gets in the chair, we don’t want to waste any time,” Bahri said. “I look at it from the patient point of view.”

Dentistry as Job Shop

In dentistry, conventional training told dental students to schedule patients by batching like procedures to avoid setups.

When I made your appointment I would see how many fillings you had and I scheduled them together. I had a different setup for crowns so the next time you came, I would do the crowns. Most of the time, dentists tried not to switch from one type of procedure to another in the same appointment because of the time that it takes to do setups.

He estimated the typical dental setup of preparing tools and materials takes about 15 to 20 minutes. Thus, a patient needing a root canal and crown even if they are for the same tooth will need a separate visit for each procedure.

The problem is that in your mouth, you need crowns, fillings, root canals, veneers, etc., Bahri said. So when you come to me, I should have the flexibility to go from one to the other nonstop. That puts the mouth at the center of the process.

Batching dental procedures avoids setups but leads to other wastes. For example, if you arrive for a dental appointment needing a procedure other than the one scheduled (like a root canal instead of a filling) the tools and materials for the scheduled procedure must be removed while tools and materials for the new procedure are set up.

Even if the appointment goes according to plan, traditional scheduling extends treatment time. For example, if you need a root canal, two fillings, and four veneers, you’ll need at least three appointments. That means three roundtrip drives to the dentist, three periods away from work or leisure, and three times the chance that at least one appointment will have to be rescheduled.

It was organized like mass production. I wanted to change that. I don’t think healthcare professionals realize how much their offices are influenced by mass production assembly lines. By removing these wasteful activities, a lean transformation gives healthcare professionals more time and resources to spend on personal patient care.

How Long to do a Cleaning?

Here is his explanation for what dental procedure was performed most often and how he arrived at a takt time for that specific procedure:

Bahri analyzed an annual history of procedures performed in his office to determine what was done most often. Cleanings at 3,985 were the runaway winner. Dividing by this number the available work time of 104,160 min., the time the office is open during a year, gave him a takt time of 26.13 minutes. Every 26.13 minutes we had a cleaning ordered, he said. Despite this stable average rate, the workload of hygienists varied greatly day-to-day. Some days the two office hygienists didn’t have enough work to keep them busy; other days Bahri had to bring in a third hygienists to help.

The next question was, “How long did it take to do a cleaning?  Bahri said. Using takt time and cycle time data, Bahri could calculate the number of hygienists actually needed to meet the rate of demand for cleanings (the takt time) instead of applying the traditional dental management formula of having one or two hygienists per dentist. He also would be able to distribute cleanings evenly throughout the schedule, eliminating the peaks and valleys of too much or too little work for hygienists to do.

Equipped with a stopwatch, pencil, and paper, Marisa Young, an office flow manager, studied hygienists working. She and Bahri discovered that a cleaning could be done in 20 minutes, six minutes less than the takt time, after nonvalue adding activities, such as walking to dentists’ cubicles and cleaning up between patients, were eliminated. Dental assistants and two flow managers took over the hygienists’ jobs of cleanups, collecting payments, presenting treatment plans, and making appointments.

Every 26 minutes a cleaning was ordered so hygienists had six minutes of free time in between cleanings, which is okay with me, Bahri said. It can’t follow the same drumbeat as an industrial process. And at that time, I was allocating an hour for cleanings, so I had cut it by half.

The Results – Applying Lean to Dentistry

Below are the results of his application of Lean Thinking to dentistry:

Mark Graban, at Leanblog, held a Q&A with Dr. Sami Bahri regarding his application of Lean for a dental practice. Please go there too to read more.

Below are two videos of Dr. Sami Bahri, the lean dentist – these videos are worth watching.

The post The Lean Dentist: Book Review of Follow the Learner appeared first on 6sigma.

[contentblock id=35]

Here’s the description of Lean Six Sigma Logistics:

Reducing costs, rushing to market and accelerating lead times are vital for survival in today’s competitive environment. Inventory is no longer considered an asset, and strategies need to be in place to operate with minimal amounts of it. Lean Six Sigma Logistics illustrates how to integrate Lean, Six Sigma and Logistics into a cohesive process that will help eliminate unnecessary inventories through disciplined efforts to understand and reduce variation, while increasing speed and flow in the supply chain.

This how to book provides the vehicle to solidify strategic position, win over customers, and achieve increased profit margins. It is the one book that executives, practitioners, consultants and academics will all want on their bookshelf. A must read for the CEO, CIO, CFO, COO, VP, Director, or Logistics Manager.

Key Features:

• Provides a method to develop strategies as well as tactical steps for successful operational implementation of Lean Six Sigma Logistics
• Addresses top management concerns while providing necessary tools and guidance for the logistics practitioner
• Features the Logistics Bridge Model to serve as your compass and map for leveraging value, eliminating waste, and enhancing your abilities to view the supply chain with a critical eye and to develop a vision for continuous improvement
• Presents definitive answers for improving operations, making customers happy, and reducing logistics costs and variability

The post Book Review: Lean Six Sigma Logistics appeared first on 6sigma.

[contentblock id=35]

In general, I thought the book was very good. The lessons contained therein are timeless and, while at the time they were revolutionary, for most lean practitioners today they might seem very obvious. But, still, while they might seem obvious, to many companies and organizations just starting on their lean journey, Shigeo Shingo’s ideas will be refreshing and revolutionary.

From the publisher:

Dr. Shingo explains the ethos of Toyota’s production system, with examples of how other companies benefited and struggled with these principles. Kaizen and The Art of Creative Thinking is the genesis guide to the foundations of the Toyota Production System.

• How to create an innovative company and culture
• How to manage a creative environment
• How to focus your resources for successful growth
• How to create an internal engine of idea generation
• How to harness the true value of improvement, and
• How to unlock human potential

Dr. Shingo’s Scientific Thinking Mechanism was born in the 1950’s and has never been fully revealed to the West. This is Toyota’s secret weapon. From this day forward you will now have the power and knowledge to start the process of implementing your own Lean system.

And, a few reviews from Amazon.com:

“Dr. Shingo was a master of Kaizen, he had the scientific training and innovative genius to deeply understand processes and the humility to realize that he needed the operators to take ownership. We are fortunate to have this new opportunity to gaze deeply into the thinking of one of the true geniuses behind TPS ”Dr. Shigeo Shingo.
From the foreword by Jeffrey K. Liker, Ph. D., New York Times bestselling author, The Toyota Way

“This book contains a myriad of case studies taken from office examples as well as the shop floor. It is a gold mine of improvement ideas that cumulatively must have saved millions, and could still do so today!
Don Dewar, President & Founder, Quality Digest Magazine

Kaizen and the Art of Creative Thinking is a revealing book and is the genesis manuscript to the Lean Manufacturing mindset. It captures the fundamental thought process to structure problem solving activities and is the foundation to all essential aspects of the Kaizen philosophy. Truly a wealth of knowledge, wisdom and frameworks to embolden you to change existing practices!, Michel Mestre, Ph.D. Professor, Northwest University

For those of us who have revered the work of Dr. Shingo, this is an exciting work. More so than any other of his books., Bill Kluck, President, Northwest Lean Network

Practicing Kaizen (the habit of making small improvements) eludes many people. Dr. Shingo’s Scientific Thinking Mechanism replaces the hope for a flash of creativity with a reliable and learnable habit-building approach. Thanks for making this Rosetta Stone for Kaizen available to the world., Hal Macomber, Principal, Lean Project Consulting, Inc.

I’d say the biggest and most positive element for me was the simplicity of the book. There is a sense of profound simplicity – but the simplicity is also very deceptive, because the principles that underlie them are quite complex and rigorous. Yet, Shingo is able to share them in a way that is accessible to everybody.

I highly recommend this book.

The post Shigeo Shingo Kaizen and the Art of Creative Thinking Book Review appeared first on 6sigma.

In the book, he mentions “several tools” and calls one of them Lean. In his explanation, he doesn’t consider Lean a management system, but rather another tool in the process improvement toolbox. It’s a very newbie way of looking at Lean. My opinion.

[contentblock id=35]

And, his writing really got under my skin AND, while this book is a good resource for Six Sigma practitioners, it’s really not something one would want to read next to the swimming pool, or while relaxing on the couch, or on vacation.

But, it’s a good resource.

If you’re price sensitive, there are plenty for sale on amazon that are used and are super affordable.

The post Book Review: Implementing Six Sigma appeared first on 6sigma.

[contentblock id=35]

My favorite parts of the book was his simple way of teaching the principles of Lean using everyday examples, such as a lemonade stand and Netflix. He does so in a way that is simple, but not simplistic. I think that chapter will resonate to most people with experience and are new to Lean. I also appreciated Jeff Hajek’s treatment of the “Respect for People” pillar in the Toyota Production System.

Overall, I liked the book. My criticism is two-fold: the book title. And second, this book is very basic and won’t really add much value to bookshelf of lean books.

My evaluation protocol is this: Could I do without this book?

The answer is Yes.

So, I don’t recommend you get it.

Despite the adage, most people judge books by the cover. The book title sets the tone for the book and I’m not sure if the playful book title aligns with the serious and educational content of the book. Other than that, I recommend “Whaddaya Mean I Gotta be Lean” by Jeff Hajek.

Jeff Hajek is a Lean consultant and founder of Velaction Continuous Improvement.

Below is also a video of Jeff Hajek teaching a video tutorial on the 5 Whys or Root Cause Analysis.

The post Book Review: Whaddaya Mean I Gotta Be Lean appeared first on 6sigma.