For those of us in a software product delivery environment who have been seeking potentially shippable product increments at the end of each sprint, it's rather clear what we're expecting: one or more small slices of product functionality that are tested, complete, ready to go, and shippable. This, of course, does not mean we must
release into the production environment what has been produced, but we could
if we wanted to. This has become the holy grail of software delivery — having our teams deliver completed, usable slices of product functionality.
Some have humorously, if not erroneously, called this achieving a state of sushi maki delivery — slices that are all about the same size (think sprints), an integration of ingredients (think Development Team), a wrapping that keeps things together (think ScrumMaster), and the ability to consume pieces of valuable product one increment at a time (think product owner). If you don't like sushi, maybe lasagna or layered cake fits the bill.
But what does "potentially shippable" look like when delivering a nonsoftware product? We need to reflect on why, in software, "shippable" is the goal. When we consider what would be the most valuable thing we could produce in our software product by the end of the sprint, it typically would make sense that the most valuable thing we could produce is something ready to be released. The key words here are "most valuable."
While building a large, complex software system from scratch, we shouldn't expect that at the end of the first sprint the teams will be able to produce a potentially shippable product increment that represents the entire product. Instead, teams will be delivering other small valuable items that contribute to the larger whole. But we don't want to get caught in the trap of believing it's all about being potentially shippable. There is also the need to learn
more about the product we're building. For example, the teams might first deliver validated learning about a new tool or technology, or their ability to integrate a vendor's API into their standard libraries. Of course, we would like the teams to try and deliver something
releasable, but there may be valuable nonshippable deliverables that make just as much sense to pursue.
Our new thinking on the idea of potentially shippable is that no matter what our product is, we should always be asking the question, "What is the most valuable thing my team should learn next, and what can they accomplish in this coming sprint that the customer or user can inspect and validate?"
So, how do we determine what's valuable? Because both our customers and our teams have gaps in their knowledge of the product, while we are sprinting oftentimes value is generated through empiricism and discovery, increasing our knowledge and reducing risk. This perspective allows us to apply Scrum in a variety of places.
In many physical product organizations, one of the first things produced and delivered to the customer is the design of the physical product. This may take many months or even years to produce, and at the end of this design phase, what do we have to show the customer? A design document. Design does indeed have value! There are gaps in knowledge about a design, though, because design is not a complete picture of reality. What we often see, though, is discovery in later phases as physical formation proceeds and customer feedback comes in that our design needs to change — at great expense.
Seek out the most valuable, inspectable delivery for this new product that maximizes learning. Allow for just enough design and expect the design to change as the learning increases.
- We identify the riskier aspect of the project, where we have the least amount of knowledge, which is our customer's acceptance of the physical dimensions of the product. In the early sprints, we could decide that a physical model is the best thing to produce, adequate enough to allow the customer to physically inspect the dimensions we are proposing. Our friends at ARCA decided to build a teller machine made of wood for an early sprint delivery, so that the customer could verify the dimensions in real space.
- The customer is interested in more lightweight materials for the new version of their product. The team could decide that the most valuable delivery for the customer to inspect would be materials validation tests to ensure strength balanced against weight and cost.
- Our customer's primary goal is to reduce power consumption for their next release of the product. The team could determine that validating certain component alternatives would be the most valuable delivery to show to the customer.
For Scrum to transform the world of work, we need to expand our thinking of "shippable" to account for increments of delivery that don't necessarily need to move into production but may very well be just as valuable, by allowing the customer and the team to inspect and validate these incremental learnings.