Last update: 02/06/2016 13:53

Shippable Software. Really?

There is a terrible mistake in how Agile methods (and more particularly in the world of Scrum) present the increment of an iteration. What Scrum pretends is that any sprint is punctuated by a PSI (Potentially Shippable Increment)[1] . We very much prefer the acronym of SAFe for that matter: WSI, which stands for Working Software Increment. In other readings, we now tend to see appearing "usable software", which is even more preferable than WSI. Our discomfort is more in the term shippable than with any other word of what a PSI is.

It can be Shippable. It Must Not.

It can be shippable indeed if an MVP, Minimum Viable Product, exists and if the underlying product can evolve in little increments. In that true sense, we indeed have "increments" that are shippable (e.g. in an Invoicing package, there can be a separate module that makes it possible to create recurrent invoices; this module can be considered as an increment that is shipped later).

The same reasoning can be followed if the product can indeed be delivered in slices (hence, the MVP can be built in a single iteration, otherwise you will always have iterations that prepare the MVP and therefore the first true shipment). This is indeed the case of a website for example (e.g. a full section of a site can be delivered later in a forthcoming increment), but may be impossible to achieve in very large projects such as the construction of an "Internet & Mobile Banking" platform (e.g. It would make no sense to deliver [2] an increment of a global framework it only the Page Bus for Windows Phones has been created and tested).

Fix-Length Iterations?

In our opinion, this is where the Agile mockery starts: by pretending everything can be completed in a fix-length iteration, posed at the beginning of the project. THIS IS NOT TRUE. And by the way, there is NOTHING that prevents Agile Teams to work with variable-length iterations. Ask Oracle if they can produce from scratch the next version of their database, ask Microsoft if they can create the next Windows in 15 days (even a Windiows MVP), ask Facebook if they can provide the next social network in a single run, … Examples are numerous and they're simply the day-to-day reality of Scaled Agile. It is therefore crucial to stick to real agility vs. doing so because the manual says so.

Actually, all resides in the maturity of the organization and its context [3] to clearly define the Minimum Viable Product. It must be as small as possible and still have undisputed value … for the user that is targeted. Not business value! User value! Woaw, say that again!

User Value

Delivering an increment is a question of user. For example, in the foundation of an Internet & Mobile Banking platform, you may come to a point where you have decided to deliver a small fraction of the global framework/API because it is completed (has reached your DoD — Defintion of Done) and bears value for downstream teams to use. Yet, the overall business value is null (or very next to zero) until you have reached something more lofty. The important point here is to cleary define the user (which by the way can be numerous in types) you target with an increment (and to undestand your transaction costs, the cost of the delivery verus the benefits of the delivery). We hope you see the subtle difference.

Valuable and Usable Software Increment from a user perspective is definitely summarizing our thoughts about the matter. And here we coin a new acronym: VUSI.

Footnotes

[1] … To be complete and completely impartial, only the term "shippable" creates some embarrasment, a term that has completely disappeared from the Scrum Guide. Heere is what the Scrum Guide says: The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team's definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it — Scrum Guides - Increment

[2] … We imply a real delivery to production, something that is brought LIVE

[3] … A Minimum Viable Product can be substantially different in function of the context. For example, the Social Network MVP #0 is not the same MVP as we would define it today

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X