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".
Top comments (3)
Ah well, fortunately for me I'm in the business of helping people with the "practice"!
However, I do think that a lot of the issues you allude to in convoluted build processes stem from a lack of consideration of the "theory". It's all too common to see organisations that start by downloading Jenkins (or similar), aren't sure what to do next, so proceed to create a rat's nest of interlinked jobs with a few manual processes along the way.
It might be more helpful to draw the distinction between the "why" and the "what" rather than between the "theory" and the "practice" - and it is the "why" that informs the process of doing the right "what"!
There's an additional argument to be made here: time to market. The life cycle of a feature from inception to ceasing to be relevant is that there is a point in time where it starts generating business value. The time before that is cost and the time after until it is taken out or the product dies is the aggregate value the feature will generate throughout its life. Put simply, you want to maximize the latter and minimize the former. The counter intuitive thing is that for a lot of features, shipping early really matters as software tends to have a limited shelf life and competitors will be eager to copy successful features. Being late to market can make a dramatic difference for the overall value generated. This can get to the point where being 10x better at the cost of a few months extra development is completely wiped out by the fact that you are too late.
So unnecessary delays are bad for business. Being late eats into the overall value you will be able to derive from development. Modern software development competes on cycle times. A year can make the difference between owning a market and having to write off expensive R&D.
Yes, this is a good point, though it might have been stretching the metaphor a bit too far to introduce the "Cragel" as a threat to our business model!