Archive | July 2015

What Lean is all about


Check out this tweet by Michael Ballé!

This is a damn good definition of Lean: “satisfying customers by developing people”. Great improvement from old-time definitions about “improving processes”, “eliminating waste” or the horrifying “cutting costs by firing people” (well, this has never been a serious definition, but sadly many people interpreted lean methods like that).

Please, don’t take me wrong: improving your processes and eliminating waste (mercilessly) are great things to do, but they are means, not a goal. Cutting costs is fantastic too, but it must be more the result of your efforts to create value and satisfy your customers than a goal by itself. And firing people, well…  Developing people so that they can satisfy your customers is the only recipe to long-term success, which is the ultimate goal of any company.

The rules to improve anything


This picture is an old-time classic about communication. Originally made as a joke about how software is developed, it has many different layers which represent very well many of the problems of lean deployments:

  • “What the customer really needs”: First rule: listen to your customer and make the goal clear. No goal = no way to know how success looks like. Simple.
  • “How the customer explained it”: Second rule: go to the gemba. Customers are typically good at explaining their pains and setting a goal (e.g. “ship my product quicker”) but they are not always so good at explaining why things happen (e.g. “you don’t have enough trucks, my product waits too long. You should buy more trucks to be able to ship product quicker”). The best (and only) why to find out what to do is observing the process. Do it.
  • “How the business consultant described it”: Third rule: improvement must be developed by those who really do the job. Experts are ok and can give great value to your thinking process. However, the solution must be owned by whoever runs the process. Hiring somebody and asking him “solve this problem for me” simply does not work in the long term.
  • “How the process was documented”: Fourth rule: standardize. This does not mean “document everything” or “create human robots”. Standards are instructions to make the job in the best way possible known. They are made based on the experience of everybody. Standards must be fair and easy to change. This a great explanation by the Lean Management Institute:


  • “How the project leader, analyst, programmer understood it”: Five rule: communication. Poor communication is the main root cause of project failure (interesting article here). The impact is even higher in Lean or 6 sigma. Keep communication in mind. Tell others what you are doing and why.
  • “How it was supported”. Last rule: be ready to fail. Failing is bad, failing and not being ready for it is catastrophic. Change is mostly based in PDCA, each test proves or refutes something, so being wrong ( = making an hypothesis that was proved wrong) is part of the game. Don’t panic and just be ready for it.


Are these rules enough to succeed? No, unfortunately. But keeping them in mind can increase your chances of success!