The Myth of the Minimum Viable Product
Features, Quality or Schedule: pick one.
NOTE: Within this text, wherever gender is not key to the explanation, I am using the Elverson ey/em construction of the Spivak Pronouns.
We all understand, from update after pitiful software update, that software projects tend to deliver really unimpressive things. Your computer operating system and your phone have been updated repeatedly and even your Gramma Klein is yelling, “All these updates and nothing gets better!” Gramma Klein has figured out something that all software developers already know: software provides little of value. One of the primary reasons for this is that the modern Agile development process, the only method used anywhere for software development, is basically engineering filler. It packs a large volume into a box of engineering but, in all honesty, it’s mostly air.
Developers are paid to fix bugs and produce new features that some marketing person has decided the customer needs. Each feature is as trivial as the shriveled imagination of that marketing person and as a result that feature can easily be thrown together in a few days. In very rare cases, someone at the company decides to produce a whole thing — what we might call a product. The wisdom of Agile tells us to produce that product quickly (in a few months) and that means cutting a lot of corners. The Lords of Agile will undoubtedly prescribe that the project yield a Minimum Viable Product (MVP). Said MVP will be defined and a collection of Agile Scrum sprints will be laid end-to-end to produce it on that clearly defined schedule.
The problem with the MVP is that it is intended to be the most trivial product possible with the intention of generating buyer’s remorse while not reaching the level of buyer’s retribution. The users must be minimally disappointed or, even better, have such low expectations that they never even notice that they have been duped into buying something they will never need and that doesn’t actually work very well. If all that falls into place then the project was a rousing success. There’s only one problem: that whole process is a fairy tale.
The Panicked Choice
Here we address the Project Management Triangle, that impenetrable trilemma that software people just have to get used to. In common software circles the three points to the triangle are Schedule, Quality and Features. In the more formal case, the points are Schedule, Cost and Quality/Features. The exact formulation is actually not important since this is merely an allegory about the inescapable trade-off. Let’s stick with the more basic triangle and recite the litany as we have all learned it:
If anything goes wrong on a project you may sacrifice any of three things: Schedule, Quality or Features. There are no other options.
Those three attributes represent the topic of the panicked, terrified screaming match that occurs over the injured victim after the inevitable crisis stabs the project in some vital organ. “For the love of god, how could anything have gone wrong?!” Here is where the Lords of Agile step in and rebuke the developers saying, “You were clearly not using Agile properly because if you had been, everything would have been fine.”
That, of course, is balderdash. Agile (usually Scrum) does not avoid crisis; it simply addresses the unexpected crisis by extending the scheduled delivery date. I believe that the following quotation may be attributed to Gerald Weinberg.
[Regarding a fundamental failure in some component of a project, we should joyously proclaim:] This is not a crisis. It is the end of a delusion.
Projects involve people and people will make mistakes. Agile does not eliminate mistakes, instead it trivializes engineering to the point that risks are largely avoided. This leads to mistakes having minimal impact because whatever the developer is doing isn’t really that important.
There was a time when actual serious interesting software projects were delivering actual new and useful products. Solaris, Linux, PostgreSQL and Lighttp were developed and delivered to satisfied customers who applied them to produce real value for users. They were not developed as a loose collection of software sprints; they were developed from a design, a project was initiated and it was carried out. In each case an excellent, truly useful product was delivered. Each of these projects required several months. How is this possible? How can software be developed without stories and sprints and marketing people “visualizing” the product? In fact, it was how most of the basic infrastructure of the Internet was developed — a process that Agile advocates claim never worked.
Accommodating Inevitable Failure
If your plan is to deliver an MVP then your project is doomed. Something will go wrong. You will need to sacrifice Schedule or Quality because any Feature removed from an MVP makes it useless — it’s already minimum. There are those rare scrum-masters who will suggest that the product should be much better than the MVP; but, they provide no clear method for distinguishing between and then moving in an orderly fashion from ideal to MVP. Without that, the non-MVP deliverable is merely an aspirational statement. For this reason, projects at Sun Microsystems were organized very differently.
The Sun approach was agile before “Agile” had become a codeword for structured iterative development. That true agility did not require delivering in pieces or eschewing documentation. The Sun project was required to begin with a functional specification and other documents were prepared as needed to make sure that the implementation was well coordinated. Even for a project of this sort, problems will arise and well-researched intentions will prove to be flawed. So how could a project based upon a functional specification possibly respond constructively to the unexpected? In other words, how could such a project be agile?
At Sun, we used a technique that we called a Red Flag Review; and, since Sun, I’ve started using a technique developed by Gary A. Klein called the Premortem. A truly agile project plans for crises by identifying them before they happen — before panic seems the only rational response.
We begin with a specification and a project plan. Would we have these documents bound into large notebooks? Of course not. If the spec and project plan are longer than twenty pages altogether no one will read them which makes them useless. It is the long unreadable boiler-plate spec that gives documentation a bad name. These are simple but unambiguous expressions of what is needed and the general approach for implementation. The goal of the resulting product will be to delight the customer. There is no plan to deliver an MVP. There is a plan to deliver what is excellent and beautiful. Were we to start with the MVP, we would fail.
The stakeholders are provided with these documents weeks before the premortem so they may review them fully. A gathering is scheduled for all of the stakeholders. This includes customers, marketing folks, management, engineers and developers.
The facilitator now stands before the gathering and says the following:
It is now one year in the future. This project has completely failed and we have moved on. I want each of you to write a paragraph explaining why it failed.
The genius of the premortem lies in the fact that the project has already failed. Psychologically the stakeholders are free. The pressure is off. Even though everyone knows that the project hasn’t started, they are generally able to place themselves into the emotional state of one looking back on a failure that is no longer their responsibility. This leads to a much more realistic and useful failure mode analysis.
Each stakeholder submits eir paragraph and over lunch, or some other lengthy break, the paragraphs are organized. Duplicates are combined and general explanations are summarized into a list of distinct failure modes for review.
When the stakeholders reconvene, each is provided with the list of the reasons for failure. Now the facilitator begins the red flag review. Five columns are presented on a large tablet or whiteboard.
Failure | Red Flag | Date | Thrower | Plan B
Each failure is taken one by one. For that failure the facilitator enters a brief summary of what went wrong in the Failure column, then the stakeholders discuss the failure and identify a red flag. The red flag is a distinct and unambiguous event that takes place on a specified date. It may be a test performed by a particular person to determine if a key third-party library is sufficient to the latest task. It may be a confirmation that a particular problematic piece of software is complete and fully tested. It might be confirmation that a particular DBMS has passed a performance test using a realistic data set. On the specified date, the red flag will be tested. In the event of failure the Thrower will “throw the red flag”. These data will be added under Red Flag, Date and Thrower respectively.
For each red flag, the stakeholders will develop a plan B which will be the alternative to the original goal. This may be to choose a well-understood but not-as-flashy third-party library. It may be to drop a particular feature from the final product. It might be to modify the published customer documentation to show less impressive performance. In each case, the stakeholders assure that the feature set never declines below the MVP, which in this case is merely a measure of the worst case scenario. That plan is entered in the Plan B column and the group moves on to the next failure mode.
When the project begins, a large number of possible problems have already been averted by rational choices made outside the heat of crisis. While working for Sun, I had the pleasure of catching a red flag twice and simply calling out, “Go to plan B.” It is a very satisfying experience. In those cases, we delivered a high quality product on time missing only a few non-critical features. By establishing the project around a product that would truly delight, the missing features went unnoticed.
Agile and possibly “Agile”
So while Agile provides a rigid simplistic procedure for developing features, there’s no serious process, in the Agile repertoire, for developing an ingenious product. The whole process works because no serious challenges are considered. To develop a serious product, a spec and a plan are required. For such a plan, a mechanism for addressing the inevitable errors is needed. Agile provides no such scheme, but old school engineering combined with the red flag review assures on-time delivery of a useful product.
The myth of the MVP is the myth that engineering is a simple step-by-step procedure. Developing a product for which the top executives might make an exorbitant profit doesn’t really require a whole solution, just some features and some glitz. The Agile world has made the brilliant solution to the persistent problem an outmoded concept. We give the developer a story, ey completes the story, ey moves to the next story. If the Product Owner is in an expansive mood, ey may produce a tall stack of stories that define an actual complete and ingenious product. Ey may then schedule them out using dependency graphs and begin the standard Scrum process resulting in a complete product ready for delivery.
The problem is that for a large project, all of the Scrum teams really need to fully understand the complete product so that they can all participate in well-informed failure management. This would require a spec of some sort and a plan that all could read and understand; but that almost never happens in the Agile shop. It is impossibly rare that an Agile shop will interpret just-enough-documentation as anything more than stories with acceptance criteria. That disjoint description of the overall product is incomprehensible by everyone except the initial Product Owner and is probably not fully understood even by em.
An Agile shop may use a red flag review but the initial required artifacts, for such a review, are a traditional spec and plan so that the stakeholders may anticipate weaknesses. The intended product must never be an MVP. While the MVP may be preserved as a referent, the product to be delivered must always be well beyond the MVP. The intended product must be something in which the user will delight and of which the developers may be proud. The Yugo undoubtedly transported people from one place to another in a manner better than walking but no Yugo owner rejoiced upon receipt; and the Yugo remains the brunt of jokes and not the cornerstone of an automotive movement. The Tesla Model 3 delivered the new owner a superlative delight and forms the proud leading edge of an automotive revolution.
Real problems like climate change, space exploration and power grid efficiency are not solved easily using small incremental steps. In these cases, the first essential increment must be 95% of the solution. The MVP will either arrive too late or kill astronauts on the pad. An actual design is required and the inevitable failures must be anticipated and accommodated. It is only by understanding the full impact of the whole solution that we may provide for next steps rather than a dead end. It is only by putting our efforts into the ideal product that we advance beyond the limitations imposed by Nature and realize our true worth. It is only through disciplined and truly agile engineering that we may solve the real and imposing problems that we all face.
Julian S. Taylor is the author of Famine in the Bullpen a book about bringing innovation back to software engineering.
Available at or orderable from your local bookstore.
Rediscover real browsing at your local bookstore.
Also available in ebook and audio formats at Sockwood Press.
This work represents the opinion of the author only.
