The main benefit of having a potentially shippable product at the end of each Sprint is the ability to release the product quickly in case market conditions change.
However, usually in the first half year or more the product doesn't have enough value to be actually shipped. So why spend all this energy to make a potentially shippable increment each Sprint if you know with complete certainty that the product won't be shipped?
And most important (at least in my opinion)
Potentially shippable doesn't necessarily mean that the product make sense or is desirable from a market perspective. Just that it works from an engineering one.
I understand 'potentially shippable' as an encouragement to manage technical and functional debt:
You seem to be painting yourself in a corner here.
I don't see why a product can't be minimally viable within weeks (if not days, for example see hackathons) instead of months. It depends on the product and the market and who you are shipping to, and for what purpose.
What do you mean by "minimally viable"? Does it need to be polished? If so, how would it be minimally viable? In many cases I've seen products never becoming minimally viable because "no one would buy them". But that's not what minimally viable means. A product you can't sell, you can demo or trial, for example. Or you can give away a minimal version without all the bells and whistles for free to build user base before you introduce new features.
Keeping the product under wraps until it's "ready" (big-bang release) it's the opposite of MVP. :-)
By definition, each iteration will deliver value in form of potentially shippable increments. Since iterations iterations do deliver value, why isn't the product minimally viable? I agree it won't be great, though, initially and probably not sell-worthy.
"Viable" doesn't mean anything by itself: for what purpose it should be viable?
Who are we shipping to? Not all users have the same requirements. You can often ship to a subset of users much earlier.
A personal anecdote. At Stack Exchange we are always shipping. Let's take our own mobile apps: as soon as we had the build system created, we started using them internally. There was a build going out to interested internal employees within weeks, and an alpha/beta program for selected users. Most of these users did not see a polished, complete, bug-free app, but the feedback we got was invaluable. We are now shipping our first app "for real", openly, to the public, but there's absolutely no doubt that our earlier "potentially shippable" increments were super-valuable for feedback and field testing.
No, the main benefit of having a potentially shippable product at end of each iteration is ability to get early feedback, to show developers are actually doing something and to motivate developers to actually do something. The "potentially shippable" has nothing to do with actually being able to ship it, but fact that the software has to be in shippable quality.
In this case, there is no problem having really bare-bones product at beginning of the project, as long as customer is able to produce feedback based on it.
Part of the reason is that it is up to stakeholders to determine when the product is worthy of release, and this determination is based upon demonstrating the results of each sprint. At any arbitrary point, the product could be deemed "good enough" and released.
It may take many more iterations to bring the project to completion, but it's quite possible that a very small sub-set of features provide the bulk of the product's value, making it worthwhile to release early. If prioritization is done right, those features should be done first.
Iterative development methodologies make no assumptions about how early that "good enough" stage is reached, so it's easiest to make sure the product can always be shipped.
There is value in having a shippable product because it implies that the product quality has been kept higher than it would be if development was performed with a longer term shipping plan.
One has to keep in mind the motivation for the "shippable" requirement. In many software projects with a long development schedule, a lot of resources might go into developing one portion of the software, usually the area called "essential infrastructure" when communicating with higher level managers. This may lead to an imbalance whereby too much resources are spent on one area, while other areas, such as testing, or UI design, are starved of resources. In the end, resources may run out, and the end result is an unusable product.
If on the other hand, the product is kept "shippable", the project at least feels like it was not a complete waste, even if the plug is pulled on development mid-way.
