What's in the Potentially Shippable Product Increment (PSPI)?

There are many references to the frequent release of running software in the agile universe – of which the agile manifesto certainly gets cited the most.

One term has become very prominent - the “potentially shippable product increment” from the agile sub-universe of scrum. [In this case from LeSS - the Large Scale Scrum Framework. ’Of course’ the scrum guide itself does not use this term. The scrum guide calls it “Increments of potentially shippable functionality”]

But since the notion of the potentially shippable product increments captures so much of the practices of good agile software craftsmanship I really fell for the term and use it more often than the official term from the scrum guide.

And it is a very handy way of illustrating what is behind the ideas of Integration, Shippable, Iteratively, Product(ion quality), w

Integrated

“All [created artifacts] have to be integrated” – the stuff really has to work together (as I outlined in more detail in what exactly is continuous integration).

Shippable

Something you could give the customer to play with on their own. An installer-file, an executable, a .ear-file with deployment description, a docker image etc. Something they could really “take away” with them.

Iteratively

We know we are going to change things - let’s build them in such a way, that it is (and stays) easy to do that. Even though we deliver increments of the product we do so iteratively – we do not try to paint a picture like the Mona Lisa from the top left to bottom right. We do it with sketches and refinements and edits until we are finally satisfied with the result.

Production quality

Production quality is perhaps the hardest one to explain without painting lots of pictures. One of the best explanations I've come across is that it "also has to work when the customer can use it without the developer being around" – which implies many little things.

Those things could include:

• a user friendly way to interact with test-data if there is something like that necessary for the relevant increment
• no buttons that don’t do anything
• no spinning wheels that are not connected to any of the inner workings
• etc.

Of course this is a bad definition, because it (almost) only defines a negative-list. It only says what production quality is not. I’m still working on a positive-list, and hope to release that soon.
One thing for that positive-list that springs to mind immediately is the requirement that the code adheres to the SOLID principles – so that it only has to be changed if a future requirement has an impact on the implemented capabilities – not because something has been left over “to be fixed when we work on this in the next iteration.”

How do you define your “Increments of potentially shippable functionality?”

till next time
  Michael Mahlberg

What exactly is continuous integration?

A while ago I wrote about the fact, that a build server can't give you continuous integration, now let's look at what we might want to accomplish with continuous integration in an agile project.

Three stories and a potentially shippable product increment

Let us look at an example from a scrum-inspired project. Suppose we have three backlog items (of course not necessarily stories in the Cohn format...):

• our product can do ‘X’
• our product can be installed on Windows
• our product can be installed on Android

The ‘old’ way

In an old-fashioned project, using ‘late integration’ those requirement could easily be met by having three separate results

• a web-application where the ‘x’ can be demonstrated
• an install-package for Windows, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed
• an install-package for Android, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed

These different artifacts could even be put in the same source-code repository and built by some type of build server, but they would not have to interact with each other, because that could be part of a later integration phase.

The problem in this scenario is that there is no mandatory requirement for a functional integration between these tasks.

So you could end up with an installer on Windows that just displays some “this would be your application” boilerplate text, an install package for Android that contains a different launch mechanism than the windows version and a web application that can do ‘x’ but is included in neither.

Even if the automated tests related to each backlog item would be ‘green’ on the build server, the customer would still end up with three separate “features” that might not generate any value for them.

The agile way

Building this with a continuous integration mindset would be different. Following the old ideas of continuous integration in conjunction with the mindset of a potentially shippable product increment yields quite different results. Especially since such an increment contains all the existing functionality as usable and working software.

In this scenario we would focus on integrating the functionality and make sure that every story we complete interacts with all the other stories.

And all off a sudden, the customer would have real value – whether the artifacts are built via a build server or not. As long as the team creates a thing that really could be shipped every time it integrates a task – in the functional sense – and makes it easily accessible to the customer, the customer can just take that artifact(s) and interact with all of the currently completed functions.

No ci-server required, btw.

’till next time
  Michael Mahlberg