How does the philosophy of lean translate to programming?

Question

Our company is espousing lean philosophy into manufacturing and administration, in the vein of The Toyota Way. How can the concepts of waste reduction and continuous improvement be applied to programming and code creation? My focus lately has been just making sure that the code I write is only to support an actual process. I think root cause analysis is already deeply ingrained from hacking away problems in code.

I'd be interested to hear from programmers who follow Lean manufacturing as a tenet of their code creation, and to learn what aspects of their programming practices have been affected by this philosophy.

Edit: Any personal examples of application?

Answer 1

Mary and Tom Poppendieck wrote the seminal work on exactly this a few years ago: "Lean Software Development: An Agile Toolkit".

http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

It boils down to taking the well-known Lean principles and figuring out what, in a software development context, things like "inventory" and "waste" correspond to.

Answer 2

On my current project, I introduced some of the concepts of Lean into my team, which is very small but had absolutely no structure or process of any kind. The first thing we tackled was waste. This included removing code (including stored procedures) that didn't do anything, eliminating various people from the requirements gathering process (thus ending the "committee approach"), and improving communication by introducing some basic mechanisms such as defining limits to meetings and lengths of project-related emails. We are continuously trying to improve, and the next major hurdle for us to overcome is the delays in the development process. That means doing away with bureaucracy, mainly.

In addition to eliminating waste, we established a fairer decision-making process by letting developers interact with the customer directly, and giving the team lead (me) the power to solve problems without having to involve higher-level managers. This allows us to shorten the iterations between deliveries, which aligns quite well with "decide as late as possible."

The Wikipedia article on Lean software development is what introduced me to the concepts:

Lean Principles

• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in

Eliminate waste

The principle to eliminate waste (or muda, which is a specific kind of waste in Toyota's lexicon) has been borrowed from the ideas of Taiichi Ohno – the father of the Toyota Production System.

[...]

[A]pplied to lean thinking, everything not adding value to the Customer is considered to be waste. This includes:

• unnecessary code and functionality
• delay in the software development process
• unclear requirements
• bureaucracy
• slow internal communication

Answer 3

Andy Hunt and Dave Thomas both speak of the DRY (Don't Repeat Yourself) principal in a number of their books. I know it may not be directly related to "Lean" but it's somewhat along the same lines.

Answer 4

Did you read the Niklaus Wirth's paper A plea for lean software?

Answer 5

To illustrate what Robert S. had to say, If you've started work on a feature, it is wasted work until you finish QA/is delivered. The thought being you aren't seeing value from that work until it's in the hands of the users. This is why Lean and Kanban folks like smaller, more manageable features.

Answer 6

YAGNI is another part that translates well like DRY. The idea of just focusing on the part that I'm building and not trying to build a huge system on the first try could be an example of this.

Answer 7

Seconding the books by the Poppendiecks. Lean Software Development: An Agile Toolkit and Implementing Lean Software: From Concept to Cash are both required reading for managers at my office (and are slowly being read by the rest of the developers.

Value stream analysis has been useful to us in identifying bottlenecks and areas of waste, and we've already seen improvements based on these exercises. The principle of "Deliver Fast" is one that my team lives by - we ship small, functional updates to our software every two weeks, sometimes even faster, but we're still "Building Quality In" (another principle) by having complete automated testing, etc.

We're also tackling one of the Seven Wastes that are brought up in the Lean books - namely, defects. By doing "5 Why's" analysis, figuring out the real root cause of defects, we improving our defect prevention techniques by ensuring the same class of bug doesn't occur again. In Lean Manufacturing, this is known as "stop the line".

If you're in a smaller company, or part of a somewhat independent team within a larger company, Eric Ries' blog Startup Lessons Learned has some interesting discussions on what he calls the "Lean Startup" - apply lean principles to a startup or startup-like team.

EDIT: Worth noting is that my team was already practicing a lot of Agile and XP practices, so adopting some lean techniques weren't too much of a shift.

Answer 8

Lean Software Development is based on Lean Product Development rather than Lean Manufacturing. The relevant Toyota literature here is "The Toyota Product Development System" rather than "The Toyota Production System". Although, there is quite a bit of good guidance on the principles of Product Development that aren't sourced in Toyota. Don Reinertsen's books are a good example.

Be careful of getting trapped into believing that "The Toyota Way" and "The Toyota Production System" are the same thing. The Toyota Way is a set of principles and values that informs the Toyota Production System, just as it informs the Toyota Product Development System, and a host of other Toyota systems, from logistics, through service.

Trying to practice Lean Software Development as Lean Manufacturing might be more risk than you might be comfortable with.