If you’ve used agile, you’ve heard of creating the minimum viable product (MVP). MVP has been thrown around so much and for so long that the term’s original power is lost. The original intent is that if you make an MVP, you are making something valuable that your customers can use, albeit without many bells and whistles. Unfortunately, the phrases “minimum viable product” or “minimum valuable product” is open to interpretation, especially when the phrases’ intent isn’t clear.
It’s challenging to know when you have the right product increment to deliver to a customer. MVP is interpreted as something whole, usable, and valuable to the customer, emphasizing whole. “Minimum” becomes close to “maximum.” The MVP becomes a point of contention – leaders press to have viable mean more and more functionality, developers use minimum to lessen scope. In many cases, the minimum viable product becomes the first and only release, while any subsequent releases become minor enhancements, or worst yet, patches. The MVP isn’t put into the customers’ hands until many sprints have passed, so very little customer feedback is available as the product evolves.
Agile is based on an empirical approach: uncovering knowledge that may not be discoverable or knowable without trying small experiments. It’s a tried-and-true method, applied to all sorts of science, innovative work, and throughout the business world. Agilists use the empirical strategy of plan-do-inspect-adapt. We plan out a small work effort as a hypothesis, prob the validity of the hypothesis by developing an increment of the product, and then inspect our experiment’s results in order to extend or adjust the original hypothesis.
How can you get the most valuable results from an experiment? Test the hypothesis (in this case, product increment) in an environment close to the actual situation. Test the developed product increment with your customers who will use the product and review how it is adopted and used. The feedback from those closest and most knowledgeable about the product will produce the best test of your hypothesis.
The experiment should be small enough not to cause catastrophic failure and small enough not to introduce many change points. The experiment should be viable in that the customer will encounter and hopefully use the changes. Each deployment should have a way to analyze the experiment’s effect (built-in analytics, customer feedback mechanism, direct observations, and more). Lastly, take the results of the experiment into account going forward.
I propose replacing “minimum viable product” with “minimal inspectable increment.” The change may seem small, but it clarifies the scope, intent, and article. Minimum means the smallest amount or quantity required in absolute terms, while minimal refers to being the smallest amount or degree in non-absolute terms. Minimal give you more flexibility to produce something that is not the complete product. “Inspectable” points to the purpose of the product – something that can help guide you to determine if you are building the right thing. The result of a sprint is an increment or product. Replacing “product” with “increment” infers that product development will continue.
These changes may seem academic, but words matter, clarity is essential. I’ve seen many agile shops that continue to skirt the intent of agile either through ignorance or to maintain a sense of predictability. Agile is about inspecting and adapting, and you can get the best results if you adopt a more experimental approach. Thanks for reading. I hope this helped.