OPINION: Of MVPs and Highlander

Warning: The following content is a single person’s perspective and not intended to replace any official guidance. No warranties, either expressed or implied, as to the merchantability, authoritativeness, correctness or even entertainment, are claimed. Read at your own risk. 

Introduction 

The Department of Defense recently made great strides in acquisition reform by unleashing the DODI 5000.87 Software Acquisition Pathway (SWP) and giving interim authority for Defense Business Systems (DBS) to operate under its auspices instead of the DODI 5000.75 DBS Pathway.   

The SWP presents a significantly streamlined acquisition process that reduces wasteful documentation, enables teams to go after technical development faster and provides a framework that is more compatible with Agile software engineering principles. Kudos to the team that developed it and to DOD leadership for recognizing its applicability to DBS. Having said that, there are a few key areas in which 5000.87 still need some clarity. The most significant among these is the discussion around Minimum Viable Products (MVPs) and Minimum Viable Capability Releases (MVCRs). 

MVPs and the Highlander Principle 

MVPs are one of the most essential elements of Agile software engineering and are directly defined by the Agile Alliance. Conversely, MVCRs are an acquisition terminology, not directly traceable to the Agile Alliance, which helps government officials validate they are making acceptable progress with their investments. MVPs are generally low to moderate fidelity while MVCRs refer to mission-capable products intended for production use. MVPs might just be clickable wireframes, but MVCRs should represent production systems with full authority to operate (ATO) and use production data. 

MVPs exist to promote the inclusion of end users from the earliest point possible, so development teams can obtain high-value feedback throughout development. For MVPs, earlier is better. Substantial refinement is not important at this first release. In fact, MVPs need not even be deployed to a production environment or show actual data. They really only need moderate fidelity of what the product might look like, so users can begin experimenting with it and offer early feedback. Getting good feedback with as little investment as possible is the key here. 

As the mantra from the movie Highlander states, when it comes to MVPs, “There can be only one” (Mulcahy, 1986) per major feature area. For any given feature area, one should not continuously keep executing MVPs because that does not make any sense at all.  I know, I know — there are several folks out there with the opinion that there could be many MVPs. But if we use the English language as a guide, this truly makes no sense. A minimum is really kind of absolute if you think about it, right? If we say this is the absolute lowest level of capability we can release before a user can provide any feedback, then why would we ever release another MVP? Are we really going to release a second product that is just as minimum as the MVP? No. I do not believe we should. 

At PEO EIS, we are working with our teams to focus on getting to an MVP at the earliest possible moment in time, even if it means working in a demo environment. This enables users to provide key feedback and start meaningful development of user stories. What happens next? A series of small incremental releases that build to a fully working product. 

Imagine a banking application: We want to start with the ability for users to view their transaction activity with analytical insights. A great MVP would be to start by showing users their transactions, so they can start providing ideas about how they might want to view them and what additional information they may want to see. After we release the first MVP that only shows raw transaction data, we can add in new user requested features.   

Let’s say users want to see a breakdown of transactions by category. To do that, we keep building toward that feature set with subsequent releases (i.e., Release .1, Release .2, etc.) until we deliver those new capabilities in an MVCR while continuously getting feedback along the way. It might look something like this:

Notice that we start with an MVP, get a substantial amount of user feedback and then enter into a series of releases to incrementally refine and build the new capability until it is ready for users to consume in production. After several releases, we add in new features over time such as search and analytics. 

As new major features are added, the team may introduce new MVPs for them. For example, let’s assume the next step in the banking application is to add in check deposits. We would likely plan for an MVP for Check Deposits and start getting user feedback on that feature as quickly as possible. That way we could begin a series of subsequent releases to get that feature to production. 

MVCRs — the Measure of Success 

MVCRs are important from an acquisition perspective. As we try to do more with our existing investments, it is essential that the DOD accurately identify investments that are providing value to the Soldier and consider altering its approach or divesting if necessary. An MVCR sets a key milestone where we have enough functionality with full Authority to Operate in a production environment that can capture and display authoritative and official data. It is the moment in which our solution is alive and in mission-capable state. However, it is purely acquisition terminology designed to track effectiveness of investments — and not a part of an Agile sprint team’s focus.   

Don’t Acquisition Your Agile 

The true rationale for this piece is that MVPs, as defined in DODI 5000.87, can confuse development teams. We frequently see milestone charts with many MVPs. Those MVPs have become synonymous with incremental releases. When questioned about the presence of so many MVPs, teams usually point to DODI 5000.87. However, if one reads the DODI 5000.87 with a lawyerly perspective, it is clear that it does not really require multiple MVPs. In fact, consider the following section:  

3.3.b.4 – “The PM and the sponsor will use an iterative, human-centered design process to define the minimum viable product (MVP) recognizing that an MVP’s definition may evolve as user needs become better understood.” 

Notice that this guidance refers to the minimum viable product, which is awesome and in full alignment with the Agile Alliance. Also, notice the unfortunate inclusion of the segment “... an MVP’s definition may evolve as user needs become better understood.” This is where folks get confused because there is ambiguity. Does it mean we should keep doing MVPs beyond the first one to keep addressing changes? Or does it mean that during the course of developing an MVP, we may refine the backlog to address user requirements? Generally speaking, you release the MVP, collect user feedback and then move on to a series of releases to address user feedback. But you generally use just one MVP. In fact, the Terms section of the document clearly describes an MVP as “an early version of the software.”  In other words, to paraphrase the movie Highlander, “there can be only one” MVP. 

Section 3.3.b.5 correctly asserts that “the MVCR for applications programs must be deployed to an operational environment within 1 year” — clearly articulating the intent that a fully operational capability must be deployed for MVCR. But again, another ambiguous sentence fragment muddies the water by stating, “if the MVP does not have sufficient capability or performance to deploy into operations.”  Yikes. This should never be the case. If an MVP is supposed to be a first opportunity to engage clients, it almost assuredly is neither a) exactly what customers need nor b) tested well enough to go into an operational environment. 

So what? Why is this important? 

Many milestone charts reflect MVPs taking place after six months or more of software development. Users get no chance to interact with the product for most of the development cycle. Clearly, the very intent of the MVP gets lost, and this results in waterfall-type plans. Also, words matter. Commonality of approach and understanding of terms result in more highly performing teams with less ramp-up time if we all have the same understanding of key concepts. Hopefully, this will help all synchronize on at least one little topic: There can be only one MVP! 

References 

Mulcahy, R. (1986). Highlander. Twentieth Century Fox.