A large number of words have already been written about why shipping software in smaller increments more quickly is a good thing to do; by deploying more frequently we become more practiced and our automation becomes better and less error-prone, we can "fail faster" by discovering we haven't shipped the features our customers want, and by extension succeed faster by shipping the features our customers do want, faster and more reliably than our competitors across the street.

There's an additional benefit to shipping more often that is touched on less often in the literature, namely a reduction in our inventory.

Imagine for a moment that rather than being in the business of shipping software, we are living the dream at our very own coffee'n'bagels cart with a suitably droll pun in the name.

Now, we could start out on this venture by spending a million dollars on the finest estate-grown coffee and artisan-rolled bagels, and wait for the customers to come, enticed by our viral marketing copy.

In all likelihood, this would lead to a couple of adverse consequences.

• We would run out of money before we could sell sufficient coffee'n'bagels and be unable to meet the other costs of running our cart. This is because we had too much of our starting capital tied up in inventory, leaving us with insufficient funds to keep the business alive. Failure to manage cashflow is responsible for nine out of ten small business failures, according to the Internet Department of Made-Up Statistics.

• Assuming we did survive long enough to at least shift some of our coffee'n'bagels mountain, our customers would soon start to complain that the coffee'n'bagels were stale at the point of delivery. By keeping excess inventory, we are no longer able to deliver the products that are relevant to our customers' needs, viz. fresh coffee'n'bagels.

So how does all this relate to the business of producing software?

Well, the inventory is all the software we have paid to develop - in developer salaries, Aeron chairs, and indeed coffee'n'bagels, but have not yet delivered to our customers. Put another way, this is "value" that we have potentially generated, but have been unable to realise due to our failure to deliver it to our customers.

These customers need not be paying customers of course, they could just as easily be the internal users who have been wondering whether those guys and girls over there in "IT" actually do anything other than consume coffee'n'bagels whilst sitting in their fancy chairs, and whether the all-singing, all-dancing, relationship-managing intranet will ever actually be delivered.

By keeping all this inventory of undelivered software on hand, we risk suffering the same fate as the coffee'n'bagels cart, namely exhausting our supplies of cash - or the patience of our users - before we can put the software in their hands so it can create the value they have been waiting for.

Likewise, by keeping our software "on the shelf" for weeks and months, we run an ever increasing risk that it will become stale, and no longer relevant to our customers' needs.

So, how do we go about reducing this inventory? By shipping more often, of course, in smaller increments to reduce risk, as well as reducing the quantity of undelivered value "on the shelf".