I now have a number of lean software development books queued up. It started when I saw this single bullet point in a presentation:
I’m enjoying the thinking behind lean, and I believe the techniques and vocabulary of lean makes software development more tangible to the folks we work with who don’t write code – and that’s important.
Overproduction in software development happens when you produce a feature that customers rarely use. This is one of lean’s seven deadly types of wastes. The perfect technique to manage this waste is to never create a feature without first establishing a clear value for the feature, but perfection isn’t easy. In commercial software development you’ll inevitably ship some useless bits as you discover the market and the functionality your future customers will value.
Even when you do ship successful bits, the outside world can reprioritize your software. The U.S. healthcare industry, for example, is ultra-sensitive to laws and regulations. A new piece of legislation can change last year’s “must have” feature into this year’s “meh”.
The relationship between overproduction stuck out to me because I’ve wrestled with overproduction for many years on several different products. Software vendors are reluctant to remove features, no matter how rarely used the features may be. Sales people in particular object to cutting anything they think might possibly have the slightest potential to attract a single future sale.
The basic problem is thinking of a software feature as an investment -something to protect moving forward. As Mark Lindell will tell you, code is not an investment but a liability. In lean thinking, features are inventory, and anyone who has come within spitting distance of a business school knows inventory can make cuts in the margin.
Removing a working feature is never an easy decision, but the sooner a vendor sees obsolete features as a cost and waste, the sooner the vendor can jettison the unused inventory that adds no value to the customer or the company.