In the canon of Agile metaphors, we find this model of minimum viable product (MVP) and incremental development in solving transportation needs. The model suggests that it is better to create more quickly achieved products that meet minimal elements of the overall need than it is to build directly toward a fully functional product and delivering it later. As the cartoon illustrates, the not-so-smiley faced customer is unsatisfied with the product of the car until the very end when it is completed but might be modestly and increasingly happy with intermediate products aimed at the same purpose – which we suppose is basic transportation. See this article for an example of this argument.
There are two major issues with this model. First, in the illustrated MVP approach, intermediate products are not reusable as subsequent products are created and are therefore 100% waste. By the time the customer receives what they wanted, they’ve used and gotten rid of 4 separate products. The second is illustrated in a July 2018 article by Julie Bort writing for Business Insider about a scooter sharing company. She wrote,
“How about using a scooter to get anywhere that is more than a short distance away? An hour’s commute? In the rain? Traveling with one or more friends? Carrying groceries? Taking your kids to soccer practice?”
The issue is that the intermediate products fail even the most modest transportation requirements. For example, the ability to carry passengers, to travel longer distances, the ability to carry cargo, accessibility by less nimble users, or suitability for currently available infrastructure, geography, climate, and safety equipment. The approach may only satisfy requirements for short travel for one able-bodied person without cargo in accommodating climate and geography and assuming suitably governed routes. Is that a viable product, minimum or otherwise? It could be argued that in most cases the MVP in the model is actually a small car (or possibly public transportation).
The problem lies with the metaphor, not with modelled technique (MVP thinking is a good tool). What the model appears to miss is the expected degree of reusability of elements of the earlier versions of the solution that are achievable in some software products but not in durable physical products like transportation systems. There are some software products that share the lack flexibility in defining an MVP illustrated by the transportation case. Examples of this in software development include creating replacements for legacy systems and processes where user expectations or things like regulatory constraints require that they don’t lose functionality with the replacement. So, beware the misleading metaphor, or perhaps metaphors more generally, as a communication tool whose reality may not be a good representation of the idea being modeled.
