Out with the Waterfall…

The traditional software project (of a decent size) went something like this: a team of business analysts spent months talking to the various roles of user of the future system, and captured all of these conversations in a requirements document. This would often be very large and cumbersome, but the business analysts would be confident that all the requirements had been captured, and thus it was agreed by everyone that a system which delivered on those requirements would do the job.

The requirements list went off to the software designers. Once the design was done, each stage was taken in turn – development, integration, testing, user acceptance. At the end, the user signed off saying that the system did everything that it was supposed to, the development team went off and did something else, and the software went into “production” – it was used in anger by the client.

This was usually called the “Waterfall” model for a software project. Each stage had to be completed before you could move onto the next stage, like a waterfall with several pools. And once you completed a stage, you couldn’t go back (the water only flows downhill). In a slightly different guise the waterfall model was also called the V-model relating design and test documents at each level , on either side of the V, through code at the bottom of the V.

In theory, there’s no difference between theory and practice, but in practice there is. What actually happened on many projects were endless “change requests”. Something wasn’t captured in the requirements, or the landscape changed and hence something about the design had to change. As you can imagine, the larger, and the longer, the project, the more likely that change requests were going to come thick and fast, and these would constantly change the focus of the project team.

The alternative to dealing with change requests was to take a firm line (both the client and the supplier) and try to eliminate or vastly reduce change requests, or push them to a bundle at the end of the project. This gave the project a chance to stay on schedule, but what was delivered at the end probably didn’t do the actual job that the real world situation required.

Big projects invariably suffered from problems like this. Government-commissioned projects were a classic example as they had some or all of these attributes: many different types of users, large requirement lists, long project lifecycles, changing political and regulatory landscapes.

So there was a big paradoxical choice in the land of software development. Either to deliver something without changing horses mid-stream but risk that what you deliver isn’t the right thing; or to change tack regularly in response to new, emerging requirements, and struggle to deliver anything.

This was the situation for large projects for large corporate customers ten years ago. Now consider the situation for a consumer app to be launched today. The pace of technology change is greater now than ten years ago, and thus part of the landscape is changing more quickly. Coupling that with the need to reduce the cost and time to develop apps because not everyone has big budgets, not to mention that apps may be launched to test the market without a guarantee of success, and it’s clear that Waterfall wasn’t going to cut the mustard.

….Enter the MVP concept

MVP’s goal is to launch something that’s “good enough” in the shortest possible time and at the lowest cost. The idea is still to try to capture the requirements of the users and deliver them, but starting with the most important features which absolutely have to be delivered. It’s important to decide what has to be in, and to scrutinise this by asking questions like “could that be left until later”. Once you have a list of “must haves” a team can develop a product that delivers these features.

Once out in the marketplace, the next step is to monitor feedback from users and then decide what’s going to be in the next iteration of the product. Again, it’s important to be critical and keep the list of new features to a minimum, before handing off to the development team to deliver.

And the cycle of (decide minimum feature set)->(deliver new version)->(get feedback) can continue as many times as you like.

A critical element of the cycle is getting feedback from users. Hopefully users will appreciate the short timeframe to deliver the first iteration, albeit with a small feature set. After some use, users will start to say “it would be great if the app did x”, and, if enough users say the same thing, feature x might make it into the next iteration of the product.

This approach is born out of and requires that the development team operate in an Agile way (a whole, additional subject in itself). The Agile manifesto which drives many of the methods and techniques in current use in software development lays out principles which respond directly to some of the criticisms made of the Waterfall model.

Lots of apps, and other software, are delivered in this way now.

Why MVP is so popular

As you can tell from the problems I’ve described with Waterfall, there are several obvious advantages which make the MVP approach popular. The reduced time to launch and cost in getting there are the big ones. The chance to react to the changing environment with releases that are planned just before development, rather than months or years in advance, is another. The chance to change the release plan, based on actual user feedback and real use in the live environment shouldn’t be underestimated.

Potential problems

To quote Einstein: “Everything should be as simple as it can be, but not simpler”. It’s worth bearing this in mind when embarking on a project using the MVP principle, as there’s a danger that the team strip the feature set back to a point where the app is no longer useable. Clearly it’s worth spending time getting the balance right between implementing just enough features and not building too many into the first iteration, and that balance can be tricky to gauge. Beta testing with a small subset of users can reveal if the app is missing a key feature that makes it unusable.

An important part of the iterative development process is getting the user feedback. This sets the genuine use of MVP approach apart from the illusion of doing MVP but really just doing a phased waterfall project. If you don’t get feedback, you’re just implementing the full, original requirement set without adjusting the product’s features based on real-world experience.

There can be a big challenge with clients commissioning an MVP project for the first time. They’re probably used to the Waterfall mind-set, and changing this can be difficult. If budgeting is important, it’s a good idea to budget for the second and later iterations, rather than spending it all in one hit and then trying to get stakeholders to agree to later phases (which are essential for overall success).

Conclusion

MVP is here to stay; it is well liked for good reasons in large parts of the software community. It can be a very powerful project template if used correctly – allowing developers and companies to test concepts with less commitment than in a traditional project.

 

Neil Tubman, Terzo Digital, April 2016.