What is the philosophy underlying lean thinking?

While lean thinking has its origins in manufacturing, understanding the domain-agnostic, abstract philosophy behind lean thinking is necessary in order to be able to apply lean to new domains.

New domains like software development or healthcare are different enough from manufacturing that lean manufacturing techniques cannot just be transplanted to the new domain.

But it is possible for any domain of human activity to apply lean thinking principles, as long as you understand, not the specific practices and tools themselves, but the mindset you must have that allows them to be thought up, to invent your own relevant tools and practices applicable to your domain and your work.

What then are the underlying principles of lean that one needs to understand to think lean?

Understanding what is value and how it is created

An activity that adds value is one that gets you closer to a finished product, a completed service or achieved goal in meeting the needs of the end customer, the person who is going to realise that value and therefore be willing to pay for it. They expect a high quality product or service, and quality is defined by meeting their needs, usually both their stated needs, and their unstated needs – things they derive value from but did not know they needed or were not able to articulate. In that latter case however, be wary of the waste of overwork – doing more than is necessary to please the end customer. If you add more value than the end customer is expecting, then make sure you are reimbursed for that somehow, whether through extra payment or customer loyalty.

How to recognise and remove waste

For something to be ‘lean’ in english, it should have no fat.

Waste is anything that has a cost (in time, money or other means) but that does not add value. Paying people to stand around waiting for something that is late to arrive, is waste. Incurring the cost of storing something that has not already been sold is waste. Making products no one wants to buy is waste. Being blocked in your programming is waste.

Sometimes the waste is obvious. Other times not so much, or while on the surface it seems obvious, the real cause is hidden. It’s important therefore to understand the root cause of any given waste that you find. Only by fixing the root cause that led to the wastage can you stop it from reoccurring. To find it, one simple technique is to ask why, five times, until you get to the bottom of it (called, unsurprisingly, the Five Whys technique)

Shared ownership of the product and the process

Just as everyone in the organisation needs to be ready to accept a state of constant change, so does everybody need to be bought into and aware of the philosophy. From management down and shopfloor up. Fortunately, once you get started this is pretty easy, as people’s enjoyment of their work and job satisfaction goes up. Churn goes down because people realise leaving to go somewhere else less enlightened will not be as good. Make sure everybody gets taught about lean – what it is, why you’re doing it, how to do it – from all disciplines and at all levels. Don’t rely on external consultants to do the transformation for you, because when they leave, you’ll still be the same, and anyway they can never know your job as well as you do, so no one is better placed to make your work more efficient than you. Become the transformation yourselves.

If your organisation is part of a chain, working with lots of other organisations, or if you are only one organisation in a bigger one, and only your division is implementing lean, then you need to understand that while you will get some improvements, you will hit a plateau when you have nothing left to improve except those things that can’t be improved without the engagement of others. It will have an exponentially greater effect if you can get your whole organisation, and your whole supply chain implementing lean practices.

Remember also that an organisation is made of people, and the organisations that are your customers and suppliers are people too. So to change an organisation, it’s really the people that need to change (or occasionally be changed, if they’re just too dogmatic).

By involving everyone, you create a shared sense of ownership in the process and in the output (the product or service) of the process. Shared ownership makes it much easier to be objectively critical without individuals feeling defensive or unfairly criticised, and it makes sure that teams work together and support each other. It avoids a blame culture. Instead of teaching people a specific way something should be done, you teach them how to come up with their own best way. To avoid the chaos of everyone doing the same thing in different ways, you have them collaborate and share their ideas. Create peer groups of different mixes reflecting the circles or spheres of influence in your organisation – everyone in a team, all the team leads, junior representatives from each team, specialists from each discipline, and have them regularly meet up and compare thoughts on improving practices and empower them to spend time, and money, to make improvements that those teams think will have a positive effect.

If something is not working the first assumption should be “it is the process, not the people, that is broken”. Equally, if after eliminating all other causes there are still problems that you suspect are down to poor individual performance, you have then successfully made the case necessary to dismiss someone from their job. And, if something isn’t working – stop doing it, look at the reasons why, and try something different. Keep trying different things until it works, and then make it even better.

Use the right tool for the job, and modify it

Lean practices form a toolkit, one that you pick and choose yourself, starting with the works of others in your domain, with books like the Lean Toolbox or Lean Software Development – Agile Toolkit, but then adapting them to your own circumstances. This is the reason why these books are called Toolbox and Toolkit!

With each new project or activity, look at the tools in your toolkit, in the form of practices, tricks, ways of setting up your work environment, ways of organising your teams, as well as physical and software tools you have, and pick the ones you think will best support you in the activity.

Adjust for size, length, complexity, experience of the team you have or implement changes and new tools based on lessons learned from previous endeavours (this is where your project postmortems should be inputting to!).

Revisit your toolbox often and make adjustments based on how things are going, don’t dogmatically stick to the approach you chose to the end of the project if new information and experiences tell you something could be improved as you go.

The greatest mistakes made in applying lean, are in copying specific practices that are instantiations of lean without understanding the principles that led to the practice being invented. Since a key element of lean is modifying and selecting the right tools to fit your particular needs, copying someone else’s approach without adaptation might not work. This is exactly the reason why the American automotive industry has not been able to keep up with the Japanese, despite regularly copying their manufacturing techniques.

Change is good

In becoming lean, the organisation must see continuous, incremental change as it’s desirable natural state. This is hard for many organisations, who associate change with cost and who are naturally conservative. Most companies prefer to do a programme of change to get from A to B in one fell swoop.

But big, disruptive, rushed change leads to high costs, inefficient processes and especially, reinforces dogma and attitudes that change can only happen in windows when big sweeping changes are approved and not the rest of the time. Organisations that try to change in such a way easily slip back into less mature practices soon after anyway.

How do you eat an elephant? One bite at a time. It’s the only way. A company that has a natural state of change is the only kind of company which is not at risk from disruption, from new competitors, from changing trends and world events. Importantly if someone ever tells you ‘we do it that way because it’s always been done that way’ – that means it probably needs to be improved if it hasn’t changed in such a long time!

Similarly, by competing with perfection rather than by watching your competitors, you will naturally become #1. Those who follow can never get better than #2. If they become #1 by some metric of volume, they stumble and fall. Like Pepsi, when it used aggressive price cutting on F&B sales to get ahead of Coca-Cola and then didn’t know what to do with their lead and got there at the expense of profit, or like Samsung, which followed Nokia, and then Apple, but once it became #1 itself, it didn’t have anyone to copy, innovation dried up, faults crept in (like exploding batteries!) and sales and more importantly profits plummeted.

Now you understand lean philosophy

Start using it today. A 1% improvement in your efficiency every day will mean in 100 days you have doubled your organisation’s productivity or lowered its costs. That’s less than six months!

Is Agile the same as Lean?

There are lots of articles on the web debating this question. Instead let’s just dive right in with the answer:

YES. For all intents and purposes, what people mean when they say Agile is a set of practices that have a common origin in the philosophy of Lean Thinking – that is, derived from examining ways for your organisation to focus on adding value, removing waste and encouraging shared ownership of process and products.

The original Agile manifesto was put together by a number of people, some of whom recognised it as a form of lean thinking and some of whom didn’t and thought they were coming up with something entirely new. Ultimately therefore a new word was used – Agile.

Lean is a good word for describing something with very little or no waste or unnecessary ‘fat’. Agile implies something that can move fast and change direction fast. Both are definitely desirable attributes of an efficient organisation.

One reason why it might not be obvious at first that lean and agile have the same origin, is that software development is front heavy with a creative process – some 80% or more of your effort (if you are doing it right) is going to be in creating something new, in engineering a product to solve a problem that hasn’t been done before. Software, once ready for deployment, can be duplicated millions of times nearly instantaneously. Lean Thinking’s origins in manufacturing on the other hand are about solving the problem of how to make the same thing over and over again but doing it the same or better each time, when those things are physical and cannot be duplicated in the way that software can.

An obvious difference in how the philosophy is applied is then that in manufacturing, throwing away completed work because of a defect is wasteful – your aim in being lean is to learn from any defects and ensure they never reoccur. In software, you will explore different approaches and create many prototypes, and if you are being agile you will test and prove them quickly and iteratively, but throw them away if they are deadends. A defect in software is a failure of the solution to solve the problem correctly. A defect in manufacturing is a failure to stick to the repeatable process. In this sense software development is akin to the engineering process that designed the car in the first place, not the manufacturing process that built 100,000 cars of the same model to a high standard. The end result is really the same – in both cases you are learning how to make a better product or how to make a better process to make the product.

It is for this reason that sometimes Agile (doing things efficiently by moving fast and failing fast) feels like a better word than Lean (doing things efficiently by removing wasteful actions) for software development, when really the key word is learning. Organisations that apply lean thinking are always learning and improving regardless of the specific practices in use.

It’s anyway true that Lean Thinking and Lean Manufacturing are not exactly the same thing. Lean Thinking is the distilled philosophy that is domain independent and can be used to develop new domain specific practices by applying the abstract philosophical ideas to that new domain.

Lean Manufacturing is the specific application of Lean Thinking to the manufacturing domain, and it just so happens that in this case the chicken came before the egg as the Lean Thinking philosophy emerged from manufacturing.

Apply Lean Thinking philosophies to software development – or indeed any activity which involves more creativity than repetition and runs in projects rather than continuous operations – and what you end up with is the Agile practices.

When it comes to the Agile manifesto however, there are those purists who believe if you aren’t doing everything on the list exactly as described, then you aren’t doing Agile properly and you will fail. For example, they say teams cannot be split across offices or countries. This is wrong, in this example modern technology can be used to bring teams together to communicate effectively. And this is wrong headed, it is not Lean Thinking. Pair programming for example is just one way to encourage shared ownership of the product. But it might not work for you, it might feel like an overhead to use two programmers to do the job of one (depending on your prejudices or gut feelings). Another way to encourage shared ownership is to perform regular peer reviews, and apply coding standards. The point is to be pragmatic, and use the tools from the toolbox that seem to fit best to your needs, or modify them as you see fit.

Key, then, to Lean is that you consider all practices that are derived from applying lean thinking to your domain, as a toolbox of ideas to pick and choose from, or to modify and apply – depending on complexity of your project, the size of your team, the maturity of your organisation and the experience you’ve had with trying different tools to see what works for you. There’s no specific right or wrong way, as long as you are always improving and learning together as teams and as a wider organisation.

The trick then is to consider Agile and related practices like Scrum and Extreme Programming to be tools in your toolbox, to consider and use in whatever combination works best for you, or even to come up with your own lean practices!

Railway ticket gates in Japan

Obviously Japan is the first country you think of when asked where did lean thinking originate (even if Deming himself was actually American). And one of the most delightful things about Japan is that you can see examples of lean thinking applied everywhere, not just in manufacturing.

One of the best examples useful for explaining lean thinking concepts to new students is the application of lean to the design of ticket barrier systems in Japan’s railway stations especially in Tokyo and in use on its chikatetsu urban railways.

In most countries, railway barriers do not open until you present a valid ticket. Therefore for every single passenger the motors operating the barrier doors must open and close at least once, and they must do so quickly to cope with the flow of passengers when it is busy. This is highly inefficient as it means the motors are straining to change direction and constantly opening and closing, so they wear out quickly and need replacing or maintenance frequently – which of course costs money. Enter a busy station in London at rush hour and the noise of the gates alone tells you how much energy is being wasted through such an inefficient design.

It also means in a fire or other emergency someone needs to open the gates and they need a backup power supply.

But in Japan, the gates only close if the sensors detect someone passing through without simultaneously presenting a paper or digital ticket. To faciliate this they are also a bit longer than you might find in other cities, taking 2 or 3 steps to pass through. Otherwise you might get whacked in the knees!

This is much more efficient – the gates use less power, the motors are rarely activated and therefore the machines need much less frequent maintenance and replacement. Instead of a gate opening and closing thousands of times in a day, it might only open and close once!

And in case of an emergency, such as an earthquake (common of course in Japan) it means people can get through who might otherwise be trapped because of power failures – sensors in the ticket machines themselves can detect an earthquake and enter an emergency state without activation being needed by the station attendant.

You could also argue that this only works in Japan because people are well behaved and conscientious, while in other countries at least one segment of the population would probably just try to run through all the time to save money. But then, you’d be looking for excuses not to try to change for the better.