One of the key principles of “lean” philosophy is that we should minimise waste. However, when following lean principles in software development, it can be possible to interpret “minimise waste” somewhat too literally. In particular, it can become easy to believe that writing code is wasteful unless you’re absolutely sure it’s going to be used without further refactoring being required. After all, why write something that’s going to have to change later?
There is a temptation to play “output golf”, where the aim is to produce the minimum number of outputs necessary to achieve your goal. If it turns out that you wrote some code, and the client wanted something different, you’ve just wasted the code (and, by implication, the time spent writing it!). In order to avoid such waste, you need detailed requirements and informed signoff before proceeding.
However, this ignores the fact that sometimes it’s OK to “waste” resources - even desirable! In particular, it’s OK to waste resources that are in plentiful supply if this gets you some other resources that are scarce. A simple example is high-level programming languages - these are generally inefficient and “waste” CPU cycles in comparison to lower-level languages like C or assembler. However, CPU cycles are (in most cases) abundant, and the scarce resource is developer time and understanding. It’s acceptable to waste CPU cycles if the end result is that the developer becomes more effective.
In a software development scenario, we might think of situations where developers are blocked waiting for customer input on a feature. In this case, it might be best to spend the plentiful resource (idle developers) in building something for your customer to respond to, as customer engagement is the scarce resource and an interactive product is the best way to get engagement. Holding up development while you wait for the “final” requirements might be more wasteful overall than doing some risky and speculative work in order to prompt some feedback.
It’s possible to use Kanban to get a sense of which resources are most scarce and which are most abundant - the classic example is that if you have lots of cards waiting for QA, your “QA” resource is scarce and you should reallocate people from other tasks, such as development, to QA. The example of customer feedback being scarce is slightly harder to infer from a Kanban board, but could be signified by lots of cards in a Backlog state that are unable to progress due to lack of requirements. In this instance, you might want to “wastefully” spend some development time creating something that will spur the input you need to complete the card.
In summary, software development is not golf and a low number of changes does not mean that you are winning. Getting working software into the hands of users is the first essential criterion for victory, and sometimes that means that you have to allow some things that feel like waste in order to get what you need to do it.
The particular phrase “waste what’s abundant to make up for what’s scarce” can be found in Eat People: And Other Unapologetic Rules for Game-Changing Entrepreneurs by Andy Kessler. I wouldn’t necessarily endorse the whole thing, but this particular point was very well made in the book.
