Minimum Viable Performance: Concept and Application in Training
Minimum Viable Product (MVP) is a concept from “Lean Startup” methodology. I believe it has a lot to offer to training problems, hence the change in the name to Minimum Viable Performance.
I have already written about MVP in my Agile articles and videos, but wanted to give this concept some extra attention.
In the below picture you can find the general idea behind the MVP concept.
The general idea behind Agile Planning/Programming/Periodization is to learn as fast as possible and avoid over-planning. The concept of MVP fits nicely here. On the following picture there is a loop from Lean Startup methodology, but it is similar if not the same to PDCA loop (plan-do-check-act) covered in Agile posts:
So, what does this have anything to do with training? A lot. I believe that most of our problems exist in the complex domain (see Cynefin framework), where couple of things are being true:
- Our knowledge of what DOESN’T work is more robust, than our knowledge of what works
- We have multiple hypotheses of what might work
- We are dealing with a lack of information and we need to probe things
- We are dealing with the uncertainty of how things might evolve
Taking the above into consideration, iterative planning and deployment seem like a viable solution, instead of upfront planning (waterfall).
So, I believe that planning in sports corresponds with the following picture:
Let me guide you through the PDCA cycle above. Once we stumble on a new problem, like preparing the annual plan and so forth, we always start with our prior (to use Bayesian reasoning) knowledge and beliefs about how things work, what is needed and what we can expect results wise. But as mentioned above, our knowledge might be more negative: we are more certain what might not work, than we are certain in what might work. So we need to test multiple hypothesizes. Since we are dealing with complex unpredictable problem, we want to create fail-safe experiments that we can use to quickly learn what we are dealing with, but also quickly adapt if things changes.
In this case we need to avoid over-planning. We still need to have a big picture (i.e. release plan) that constraints our choices, but in the short-term we plan as needed and update our knowledge as we gain new insights (information, evidence).
So what does agile planner do in this case? One needs to build very simple plan, that will yield certain results (in this case MVP), that not only creates gut check, but also brings more information in return and help us converge to the appropriate solution. In other words, we plan to build MVP, and use that MVP to update our knowledge – we use it as very usable vehicle to test our hypothesizes and learn quickly.
All this might sound abstract, so let’s cover couple of practical examples…