Can lean really be applied to software development?

Partly. What transfers is the reasoning about flow and waiting, meaning the fact that delivery time depends more on how much work is open than on how fast people are. What does not transfer is productivity measured per unit produced, because in software every unit differs from the last.

What is the difference between lean and agile?

Agile is a set of values about delivering software, written in 2001 by people who wrote code; lean is a production management philosophy born at Toyota decades earlier and adapted to software in 2003. They overlap on small frequent releases, but lean adds explicit reasoning about waste and flow.

Do you need a Lean Six Sigma certification to use it in software?

No, and the two should be kept apart: Six Sigma's main branch, DMAIC, exists to reduce variability in repetitive, measurable processes, an assumption design work does not offer. A design branch does exist, DFSS, but its statistical tools have little to bite on in a stream of requests that all differ from each other.

What is lean software development, and what does not transfer?

Lean manufacturing principles brought to software: what gets eliminated is waiting and unfinished work, not people.

Lean software development is the application to software of the principles born in Toyota's production system and popularized by Womack and Jones in Lean Thinking (1996): define value from the point of view of whoever receives it, let work flow without stops, pull it from demand instead of pushing it from a forecast. The translation to software belongs to Mary and Tom Poppendieck, who rewrite the factory's seven wastes in Lean Software Development (2003) and settle the version quoted everywhere today in the sequel, Implementing Lean Software Development (2006): work started and not finished, extra features nobody asked for, having to relearn what was already known, hand-offs, task switching, waiting and defects. The first item on that list is the most expensive and the least visible: work stopped halfway appears on no balance sheet, makes no noise and goes on costing money every week.

What does not transfer, and that is the part left out

Lean comes from a place where production units are repeatable and measurable: one part identical to the last, a cycle time worth comparing. Software is design work, where every unit differs from the previous one by definition, because an identical one would be copied rather than written again. The naive transfer always produces the same failure: the amount of work delivered gets measured as though it were parts produced, the measure becomes the target, and from that moment it stops saying anything true. That is the mechanism of Goodhart's law, and in software it almost always shows up dressed as a productivity dashboard.

A concrete example

A software house serves four clients with three developers and every request enters as soon as it arrives. Nobody is idle, and yet nothing ships: eleven things are started and none is finished, and every switch between clients costs half an hour to get back into the problem. The lean correction is not hiring: it is stopping starting. You set a cap on how much can be open at once, and new work enters only when something leaves. The time between request and delivery shortens without anyone working harder, because what was removed is the waiting, not the effort.

Why it matters for decision-makers

Anyone who lived through lean on a factory floor recognizes the pattern and then makes the same mistake in two opposite directions. One is applying the tools literally, which yields measures that do not measure. The other is concluding that none of it applies to software, which throws away the one idea that transfers intact: the bottleneck is almost never how fast people execute, it is how much work is open at the same time. That is visible in an afternoon and fixable without buying anything, and it is the practical territory of Kanban.