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!