To me, "lean" software engineering means the following:
- It produces a lean product, which does what it is supposed to do very well. It is designed for change to meet any new or changed requirements. It is composed from a set of cleanly designed modules which are well-separated in their design and implementations at all layers. There is no unnecessary complexity.
- It uses a lean process. This is a more controversial issue; many managers would readily agree on the lean product, but they have difficulty agreeing on the lean process. They immediately associate a lean-process with extreme-programming (XP). And that means chaos to many managers who grew up with traditional waterfall models. I am a proponent of a "lean" process, but not XP, for that XP has its serious flaws and I do not subscribe to all of its tenets. That is a whole another discussion altogether.
The choice of development model should depend on the nature of the project. If time-to-market is an issue and if we have 6 months to deliver a fairly complex product, we know we cannot go through a traditional waterfall process. It doesn't mean that we should not follow some of what it specifies. We do need to start with requirements gathering, but what we cannot do is to sit around for 3 months gathering all nitty-gritty requirements, with the hope that we can get them all. We will need a much more agile and iterative process, which means rapid development, validation, enhancements, leading to final product delivery. On the other hand, if we are building a software that goes into a space shuttle, we may need much more structured waterfall / RUP process.
- Finally, it employs a lean project team. Assign as many resources as needed, but not more. Identify right roles for every member and empower them by providing whatever resources they need to perform their tasks. Remember that men and months are not interchangeable (read the classic Mythical Man Month by Frederick Brooks); throwing extra resources blindly at a failing project will only make it worse.
