Scrum weaknesses and Potentially Shippable...

Jack Milunsky posted another great article on the Agile Software Development blog about the areas where scrum falls short. It's an interesting read and I encourage you to consume it. I'm a strong believer that Scrum is a great starting point, but an agile transition shouldn't end with it.

One point I didn't agree with though was this:

Potential Shippable code - what does this really mean?
Most Agile thought leaders define the output of an iteration as an increment of potentially shippable code. And more often than not, it appears to be acceptable (please tell me if I perceive this incorrectly) that this potentially shippable increment of code is not actually live production code. And therein lies my beef with Scrum.

Here's the response I left:

We have to remember that when "potentially shippable" was created as a concept, we were combating waiting months or years to ship a product. In large enterprise environments, this was an even larger/longer problem. This new concept embodied the idea that we could stop at the end of any 1 month iteration and have something working (and probably of value).

Since then, the industry at large (due to the internet and companies like Google) has embraced eternal betas, imperfect software, and constantly evolving software focused on constant value. Within agile, we've seen a migration to iterations under a month. I believe it is time to rename this to "proven shippable". This is the compromise between Jack's comments and the enterprise's needs. Enterprises build large solutions to large problems and they understand the needs of the market. When a complex domain (like banking or healthcare) already has mature software solutions, you know your product won't displace the competitor's software after the 2nd or 3rd iteration. There is effort to marketing and advertising new products. It is important to have a release cycle and the power that comes with it. You can't just dribble out small changes every week and expect to catch the market's attention.

This is why I think that in small continuous flow shops, I agree with Jack's done = production use. But in large shops with large customer bases, you might need to allow the business and market determine when to take on the new release and not force it on them. If your releases are compelling enough, they will migrate (VersionOne has mastered this!) In this case I don't think your done criteria can be production.

Thus, I propose -> "proven shippable". This means you have shipped it to somewhere external to your development group that is a proxy for the customer base.