Agile practices have become overrun with buzzwords, and in many cases misunderstood terms. One of these is the Minimal Viable Product, the MVP. If you’re a startup or an established business developing a new product, you might aim to develop a MVP and this is a completely legitimate path to take a product to market. The process might follow something like this:
- Proofs of concept (PoC): Look at the your various hypotheses and test out whether these concepts are feasible in reality.
- Prototypes: Start to assemble some level of functionality that demonstrates how this product would work… ugly but functional.
- Minimal Viable Product: Bring this together using all the learning from PoC and Prototyping into the simplest possible “customer ready” version of the product.
The main purpose of an MVP is to get a minimal version of the product in front of customers to test your customer hypothesis, which is usually a fundamental element to your business plan.
In a lot of cases, a MVP is being used by Product teams as a way of reducing scope in the face of arbitrarily set timescales and everyone hates it.
What’s going wrong?
When agile is poorly implemented within a business, the promise of faster turnaround times in software development isn’t being met, the old project management rules of thumb still hold true. You have 3 variables to play with, time, resources and scope. The agile promise is that software is delivered faster and cheaper so the only variable left to play with is scope. The team will reduce scope and call this an MVP. The result of this is often a poor deliverable with a rushed implementation in an attempt to meet the arbitrary deadline.
One thing I’ve noticed in these situations is that the process of designing the system is side-stepped in favour of developers leaping in feet first, the danger is you get each member of the team coding in different directions.
If a development department start talking in terms of everything being an MVP it’s double-speak for having the time and resources so constrained, that they have shrunk the scope to a level, you, the business guy isn’t going to accept, but call it an MVP and it suddenly sounds very “silicon valley”. Some time may have been bought for the run-ragged developers and you might start to accept this stripped down shell of a product…
How is this fixed?
Working on existing products is complicated and takes time, we need to get back to a place where the whole team, developers and all, are involved in the initial conversation. The approach, the design, the architecture need to be thought through and again, it needs to be done as a team.
By the time the coding starts, everyone should know what they are coding, what is being built and how they are going to get there. Agile doesn’t lack planning, it’s just all the planning needs to be done upfront and with a wider group of people, not just a project manager sitting at a desk pushing tasks about on a gantt chart or todays equivalent, burndown chart with backlog shenanigans. Do the work as a team, be honest about the timescales and call-out under resourcing.
So the next time you hear the deliverable is an MVP, stop and think whether thats really what’s on offer.