Scrum falls short in at least one area in my opinion

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) 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.

I come from the XP "world" where we use Spikes for any sort of research. They are time-boxed at no more than a week, and their intent is not to produce code, but rather to learn enough about a problem to be able to provide a reasonable estimate.

The output of a Spike is not intended for production use - it should be thrown away. The time-boxed aspect is also very important - the Coach/SM/PM may have to be, um, "firm" with the developers not to gold plate the experimental code. Again, the goal isn't to code the solution, but rather to learn enough about it to be able to provide an estimate for the real production work.

With respect to handling Spikes from a scheduling perspective, I tell teams that they should typically reduce their budget for an iteration by a point or two for each spike that they're doing. Also, since anything unknown is a risk and we want to make risks visible as early as possible, I coach teams to perform their Spikes as early in the release cycle as poosible. Don't have an iteration that's nothing but Spikes, but don't defer them either.

I agree that you will have spikes or research tasks that produce no real code, but that's something that is agreed upon upfront. however I believe teams should strive to have any code defined for delivery during the sprint, to be live on production servers at the end of the sprint. if you don't do this, this work just lingers on as work in progress that reduces cycle time and efficiency.

I also buy that there will be certain environments where this may not work. But I think a goal of potentially shippable code lowers the bar and is a cop out for not completing the work.

Kevin. I buy the fact that customers may not want new versions shoved down their throats every 2 weeks for example and in that case I could live with potentially shippable = deployed to production simulated environment where code is totally signed off on. i.e. this should not be an excuse to re-open the code and continue testing.

Jack