Potentially Shippable Software Isn’t Sufficient: The Glass of Water Analogy


At the end of July I spoke at the Agile 2014 conference in Orlando about what it means to be an agile enterprise.  Part way through that presentation I spoke about the differences between producing potentially shippable software, one of the mantras of the Scrum community, and potentially consumable solutions as promoted by DAD.  To do this I walked people through what I call the glass of water analogy.  Here’s how it went:

I had a glass of drinking water.  I took a sip from the glass to verify that the water was clean and the right temperature for drinking.  The water was very refreshing and was something that I thought others would enjoy.  It was my opinion that this glass of water was potentially shippable.  I took another sip and then offered the water to the audience, there was over 200 people in the room, yet nobody was willing to drink from my glass.  Shocking! I even singled someone out and tried to bully him into drinking my water (oops, I mean I aggressively marketed the wonderfulness of the water to him).  Still, nobody wanted to drink the water.   I took another sip and verified that it was in fact still refreshing.  It was clear to me that my glass of water was potentially shippable.  I could very easily have walked over to anyone in the room and they could easily have drunk from the glass.  But everyone chose not to.  It was potentially shippable from my point of view, but from the point of view of every single audience member it wasn’t consumable.  In a venue where drinks are easily available, not a single person was willing to drink from my water glass (I assume due to a fear of catching my cooties).  Had the venue been different, perhaps a desert with no other sources of drinkable liquids,  someone might have been interested.

The point is that creating potentially shippable software isn’t sufficient.  It needs to be something that people actually want to use, to consume.  It must be a true solution that adds real value for them given their current situation.  Cootie-laden water isn’t attractive when other drinks are readily available.  Similarly, software that is difficult to use compared to other options, that isn’t well supported as other options, or that doesn’t enhance the way that people want to work isn’t going to be very attractive either.

Disciplined agilists focus on producing potentially consumable solutions.  High-quality software is clearly part of this, but that software needs to be usable and something that people want to use.  It needs to be supported with sufficient documentation.  It needs to be supported with adequate hardware.  It may even be part of an overall change to the business process and even organizational structure of the people using that software.  

“Potentially shippable software” is a wonderful slogan, but we need to do a lot better than that. 

Have any Question or Comment?

5 comments on “Potentially Shippable Software Isn’t Sufficient: The Glass of Water Analogy

“The point is that creating potentially shippable software isn’t sufficient …. It must be a true solution that adds real value for them given their current situation.”

True, of course. But I think this post more demonstrates the danger of slogans, and that there’s no substitute for thinking. “Potentially shippable” is meaningless unless it’s understood as adding real value. Otherwise why would you ship it to anyone?

And analogies are essential for conveying a point. But they’re challenging. An instance of product that has undergone destructive testing (drinking from the glass of water before offering it to others) is no longer shippable, but a new, (literally!) clean instance is. I think a better use of the glass of water analogy would be to pour two glasses of water from a pitcher, drink from one to show how tasty it is, and then offer the other glass of water to an audience … of bicyclists. Nobody would take the glass of water. Why? Because water for biking has to be shipped in a sturdy, light, non-degrading bottle, sized to fit in a water bottle carrier. In that case, the packaging would make the difference between apparently shippable and actually shippable.

Differentiating between the words “shippable” and “consumable” is just pandering to the buzzwords and letting software producers avoid thinking. To understand considerations involved in making something truly shippable, have to put the water aside and actually read your post http://disciplinedagiledelivery.wordpress.com/consumablesolutions/

Valentin Tudor Mocanu

There are imho more layers:
– working software
– potentially shippable
– consumable solutions
The first ones are, indeed, great to describe the work progress made by iterative development and even more: iterative and ready to release incrementally… but the final goal is to meet some business needs, and to put in connection the solution and the business consumers.
imho the best term is consumable solutions, where the others terms are great, but only for some intermediary goals.
A consumable solution it is, of course, also “potentially shippable” and “working software”.

In fact, iterative and incrementally approach must have 3 dimensions
– produced iteratively
– delivered incrementally
– consumable each time – in order to close the full circle – up to the business feedback
Develop-Deliver-Feedback from consume

Peter Merel

Hence the importance of Impact Mapping. http://impactmapping.org


@Tom, interesting thoughts. I think that that challenge with talking about cyclists is that its too narrow of a community. For example, I didn’t know that they wouldn’t like glass although that certainly makes sense.

@VTM, very good points.

@Peter, impact mapping is one of many techniques that someone can apply to support their agile analysis efforts.

Peter Merel

@Scott, certainly, there are lots of ways at this level. Lean Startup “pivot until profit”, Design Thinking and SBCE all play here prominently. No doubt you can think of others.

But Gojko’s work on IM speaks most directly to your point – that it’s not about the shippable software, but the impact of its consumption. IM provides a concrete systematic method to identify the assumptions this entails so that they can be shared, ranked and put to the test in good order. I enjoyed a nice chat with the man last week in Sydney concerning ways of combining IM with a colouring of value stream maps, and I’m looking at how to take this into XSCALE as a continuum of VSM, IM, Feature Mapping, Story Mapping and BDD. Iterative, breadth-first and contractive. Fun too!


Leave a Reply

Your email address will not be published. Required fields are marked *