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!

Shipping containers, and keeping them full – or, how understanding lean thinking can make you rich

The Intermodal Shipping Container. A standard way of moving goods by ship, rail, road and even airplane. This might seem obvious now, but having a standard size container for shipping products big and small, that could fit on a train or a truck, or be easily stacked and loaded onto cargo ships, with standardised fittings to allow for rapid loading and unloading anywhere in the world, has only been possible since the middle of the 20th century, and all thanks to freight hauler entrepreneur Malcom McLean and engineer Keith Tantlinger.

Prior to the standardisation of the container, cargo would require huge amounts of manual effort to load and unload, and be packed and unpacked into different sizes and shapes of container depending on the ship, the port, the country, the truck, the train and always different methods of connecting and stacking things to cram the most in.

Standardising on a size that would fit everywhere it needed to go, on any type of vehicle, reduced loading times from weeks to hours – an extremely good example of reducing the waste of wasted time! It also made it much easier to use space more efficiently, and ships could even be designed around the container size multiples.

There were lots of obstacles to overcome in getting this change through though, on a global scale for it to work, and vested interests especially – unionised dock workers in particular tried to thwart their plans, because it would reduce how much work they had and make them more efficient.

But what made it’s inventors truly rich, was a simple application of lean thinking, or indeed common sense, and yet somehow not obvious to most freight haulers of the day, was that after you shipped something one way, you have to ship it back again empty, in which case you’re paying a lot of money to ship thin air.

So it was that the ironically-named McLean took advantage of the opportunity to ship military supplies from American to Vietnam for use in the war there, and then return the ships via Japan to pick up Japanese products to bring back to America, just at the time that Japanese became the centre of world manufacturing and the leading exporter of mechanical and electronic products. In the military, he also found a customer who’s biggest concern was speed and efficiency, and who had the political might to force change upon those who were stuck in their ways.

Several years later, and without any more wars taking place in Asia, Chinese entrepreneur Zhang Yin noticed that while ships were full going from China to the USA, their containers were empty going in the opposite direction and apart from being an obvious sign of the decline of American manufacturing years before their politicians noticed, she smelled an opportunity that made her China’s wealthiest woman. She researched what could possibly go in that space that China wants but the US does not, and she hit upon the one thing American’s are really good at producing – Trash! By setting up a recycling business in China, she was able to not only get paid on both sides of the deal by being paid to take away people’s paper and cardboard trash, and then ship it at discount rates by buying up otherwise unusable shipping capacity, she then recycled it in China into cardboard to be used for shipping products back to America, effectively creating a kind of perpetual motion machine, or at least, a perpetual money printing machine!

Both McLean and  became insanely rich because of this simple application of lean thinking, what opportunities to apply lean thinking can you think of that will make you rich?

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!

Steve Jobs’ sweaters

Steve Jobs famously standardised his wardrobe – bespoke Issey Miyake mock turtleneck sweaters, of which he apparently owned around a hundred, and Levi 501s.

For Steve, focussing his time and energy on the things that mattered most to him – his business and his family – was more important than having a varied wardrobe and spending even just a few minutes each day deciding what to wear, especially when in his position as a businessman and a design visionary, he might be expected to be well groomed and always wearing highly fashionable outfits (which might have taken more than just a few minutes each day).

So, he found an outfit that he liked, and he just wore that most of the time, and certainly when at public events. Doing so, for Steve, removed the wasteful and unnecessary time spent choosing clothes and matching ensembles.

This is a great example of applying lean thinking to one’s lifestyle. Not everyone wants to wear the same outfit every single day, most people find value in expressing your personality through how they dress, but for a time Steve Jobs was probably one of the busiest and hardest working people on earth, so every second he could save in his day to allow him to focus on the things that were, for him, the most important, is an example of removing waste and concentrating on value. Equally, it’s a great example of how the definition of value can be different depending on your point of view. Again, Steve Job’s time saved in not having to choose outfits or go shopping, meant more time to spend on his work and his family, and this had more value to him than expressing himself through changing fashion choices.

Lean Thinking for Risk Management

In this post we talk about GRASP, the first ever application of lean thinking oriented business transformation principles to risk management of complex projects.

GRASP is the lean method for project risk management

GRASP is a soft-systems methodology that uses stakeholder oriented analysis to make it easier for any management team to determine what should be done to ensure its projects go forward successfully, that its strategic planning is sustainable and its critical decisions more likely to gain widespread support.

The methodology makes it easier to identify less obvious but nonetheless important opportunities, search for underlying causes of risk to the project and better define the inevitable uncertainties and assumptions present in all projects. In short, the GRASP risk management methodology is for deciding on the best way forward for a project’s sponsor, its management team and for the project itself, always given the prevailing circumstances and however critical the project’s true situation.

Lean Risk Assessment and Strategic Planning

GRASP has its origins in discussions and side-debates held during the UK’s ESRC / LSE 1991 Seminar series “Rethinking System Failure, Hazard Management and Institutional Design”. The methodology provides project practitioners with a means whereby they can quickly arrive at an understanding of what exactly is happening with their project that needs fixing and what external influences could block their efforts or cause unexpected and serious difficulties. By the way this is done GRASP also makes it easier for them to see the relevance of available guidance on managing and delivering successful projects. The project’s management can then put right what is under its immediate control and bring to the attention of those responsible for matters that fall outside of the project team’s remit that could greatly affect the health of the project.

To learn more about GRASP, visit it’s home at Conspectus or buy the book on Amazon

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.