Most focus for Lean Software Development has historically been on the production principles. However, there's now a new school of thought which suggests that those principles are somewhat limited where it comes to software development.
Most of software development is about producing something new; something which has never been produced before. Because of this, most software projects have natural variance and variability. Trying to apply the principles of Lean Production to create predictable, reliable delivery can actually stifle that variance and variability, reducing innovation.
The new school of thought treats software not as a Lean production line, but as Lean product development - in that it's more like designing new cars than building the same car over and over again.
David Anderson's Kanban method, which @Pawel mentions, derives more from the new school of thought than the old. He gives the following guidelines:
- Value trumps flow
- Flow trumps eliminating waste
- Then eliminate the waste.
For instance, if you can get something that's extremely valuable to the business into production, do it before anything else, even if it means other pieces of work hang around for longer. After that, do what's needed to keep work flowing through the system. This may mean having queues or buffers like "ready for development" or "ready for test", even though those would be considered inventory, and therefore waste. After that, eliminate waste.
If you're looking for work in the Lean Product Development space whose principles can be carried across to Lean Software Development, I recommend Don Reinertsen's Managing the Design Factory and John Seddon's Freedom from Command and Control. Other works related to Lean thinking, like Peter Senge's Fifth Discipline, may also be useful.
For actual Lean Software Development, I recommend David Anderson's Kanban and Jurgen Appelo's Management 3.0.
Dan North's also spent some time looking at how to apply Theory of Constraints to this kind of variability, and has come up with the idea that ignorance is the constraint - that is, the speed at which you can learn relevant information represents the constrained machine in your pipeline. He calls the act of targeting that ignorance Deliberate Discovery, and in my experience it's a very effective philosophy. It's also the backbone of BDD and Feature Injection.
To answer your questions:
The Toyota Production System was developed by applying Lean Thinking principles to the context of Toyota, and in that respect, Kanban is very similar: it applies Lean Thinking principles to the context of a particular team. It does not apply TPS brute-force to that team, nor do most of the successful Lean Software Development outfits. (As a note, I hear that most production lines which have tried to replicate TPS have had limited success).
There's only one place where we can truly achieve Lean Software Production in the same way as a production line, and that's in continuous integration and deployment, where we really are building the same thing over and over again. Software development generally doesn't work that way.
