MVP (Minimum Viable Product) has recently become a meme – people that otherwise know very little about Agile are actively searching for MVPs on their projects.
Sadly, as with much in life, MVPs can be both a force for good or evil (OK, this may be slightly overstated). Yesterday, I was invited as an observer to a project kick-off workshop, where the first agenda item was to identify the MVP. The workshop perfectly illustrated some of the pitfalls of “MVP-hunting”, and prompted this blog.
On the plus side, looking for something smaller than the whole solution – and which is truly valuable – is an essential part of Agile thinking. It focuses attention on what value really means, how it will be delivered in reality, and how you can get there as fast as possible. MVP also steers the stakeholders towards thinking about the need for early validation of assumptions.
So what is the downside?
The first time I noticed a problem was at a client running a major programme of work. Their programme team had started by identifying MVPs for each of the major streams of work, and were busy patting themselves on the back for their inherent Agility. However, the net result was that a series of projects was commissioned that had already been reduced to the absolute minimum viable functionality, resulting in some of the most difficult waterfall projects I have ever seen.
I believe this is an example of using MVP to define scope, rather than either as part of an incremental plan or as a way of managing uncertainty through feedback loops (an iterative plan). Using MVP to define scope is the ultimate Agile no-no: entering into a dialogue with the customer about whether something less would be valuable, but as a means of negotiation. Customers are naturally going to be resistant to contemplating less if they are suspicious it will lead to them getting less.
The second problem is the main one evidenced in the workshop yesterday, and is an observation on people’s behaviour when you start the collective thinking process by looking for an MVP. The MVP was the first item agenda, and a very constructive morning was spent looking at goals and options and honing in on “the deliverable” for the short-term horizon. The plan was to use the afternoon to look at the wider project, but the mood of room was essentially “job done”, and the workshop descended into a debate about whether it was valuable exploring the wider project. One key argument was that, given that the result of the MVP could be negative, the rest of the project might never be implemented (in the terms of Adapt 2.0, this is an issue of planning in the context of uncertainty).
Fortunately, plenty of the wider project had already been exposed when discussing options for the MVP, but this is a behaviour I have noticed frequently in incremental workshops, where identifying the first increment feels like the end of the planning process, rather than just the first step. This is partly because so much effort is put into getting to the smallest possible thing, especially when engaging with stakeholders who are resistant to the process. By structuring the workshop to start with the MVP, the impact of this tendency was exaggerated.
What ultimately happened in this workshop was an agreement that the next step would be to seek funding approval for the MVP. This leads straight back to the first issue: there would now be a project commissioned which has been pre-scoped and has a very fixed, singular outcome, rather than being part of a larger journey.
The final problem evidenced yesterday is a more subtle one, and relates to whether the MVP is being viewed as part of a wider iterative plan (in which case the MVP is the minimum required to get valuable feedback) or part of an incremental plan (in which case the MVP has to be of a quality which is operational). The room as a whole was far too content to switch objective when it suited the argument at hand. The conversation started by defining the MVP as a test. On deciding that the funding would be sought for the MVP as a standalone piece of work, it was collectively agreed that the MVP had standalone ROI. When challenged on the architectural approach the MVP was suddenly being described as a “proof of concept”.
To resolve these problems at IndigoBlue, we generally try to move away from looking for an explicit MVP – rather, we generate the overall incremental plan, then label increments by what they achieve rather than using generic labels such as MVP, MMF etc. Besides any other benefits, it stops debates about the right definition of the generic label. In this world, a proof-of-concept release might be a first incremental step towards a fully operational solution. Which one you call the MVP becomes irrelevant.
As with many Agile techniques, MVP is useful to beginners to promote incremental and iterative thinking, but like most simplifications it has its dangers. Hunt MVPs with care.
If your organisation is looking for support with its Agile planning and incremental delivery, please get in touch.