The core principle of the lean approach is to focus on value for the customer and at the same time eliminate waste. “Value” is defined as any action or process that the customer would be willing to pay for. “Waste” in turn is any action or process that does not add value.
The focus on value
In software value is what users will value once they start using the software. Such value, however, is very likely to change in time if only because users may often not know exactly what they want; what is more, when they see the software “in action”, their idea of what they want will invariably shift.
Making improvements little-but-often creates a learning environment which allows to truly discover and deliver value to end users. The first version of Gmail was literally written in a day and in the early days every new feature went live soon after it had been programmed, and most new ideas were implemented shortly after they had been conceived. It is the subsequent users’ feedback / behaviour that helped to establish what was valuable and directed the effort towards the outcome we are able to appreciate today.
Lean defines waste as anything you do that does not add customer value or delays the delivery of value to customers. In software development this may translate into the following common forms of waste:
Partially done work
Some examples of partially done work include:
- specifications and requirement documents created too early
- code which is not covered with tests
- code which is not deployed to production
Some of the practices which helps to eliminate partially done work are to divide the work to be done into small batches or short iterations and do detailed requirements specifications just before an iteration. At the end of each iteration, it is a good idea to stick to a simple rule: either code is integrated, tested and accepted, or it does not count at all.
Frequent deployments have an additional benefit of reducing the risk of delivering wrong features, because the users who start using a minimum feature implementation can often immediately provide valuable feedback with which to decide on how the feature should be developed further. Therefore, avoid writing requirements too early – in each iteration you learn something new which positively affects your ability to structure the contents of the next iteration.
Pages: 1 2