The discussion centred upon whether “MVP” – Minimum Viable Product – is a concept that has been usefully applied in practice.
In theory this approach focuses on getting a subset of the full requirements of a project implemented and delivered early into the hands of users and then this is iterated upon and incrementally developed in response to feedback. The view from around the table was pretty gloomy in terms of real world examples.
While one team had a successful experience in providing a system fulfilling the requirements of a single customer and releasing before extending the system to other customers, most of the group had less happy stories:
Business Moves On…
In some situations the business has funded an MVP approach and the initial stage has been completed and deployed, but instead of this forming the basis to gain feedback and steer further development, the business has been champing at the bit to move on to other priorities and the original project never gets beyond the MVP.
While stopping a project after the MVP stage is a perfectly valid outcome if feedback dictates that there’s no value in delivering anything more, in some cases the decision had already been taken to stop the project regardless of what customer feedback indicated.
MVP = “Maximum Viable Product”
Possibly borne out of the first scenario – where past experience has burnt people and they have a strong suspicion that anything not in the MVP will never get delivered, or perhaps will be delivered but subsequent phases go to the back of the queue, stakeholders push go get all their requirements into the first release. This is especially likely in cases where there are fewer development teams than there are projects/stakeholder groups.
This develops into a self-fuelling situation where Project X’s MVP encompasses all possible requirements so that they get everything up front and don’t get stuck behind Project Y for a second phase with useful but lower priority requirements. Project Y in turn is expanded in exactly the same way because they are worried that Project X phase 2 will take a long time before resources are free for their own next phase.
This leads to teams working on features that are low priority/low value to the business but high priority for their stakeholders, rather than always focussing on delivering the highest value to the business.
“Get out of jail free”
Some members of the group described a situation where the teams have embarked on a project to deliver a full scale project and then when things started to go off track they pulled out the “MVP Card” to reduce the scope of the project retrospectively. It was agreed that to undertake a project using the MVP approach this has to be declared up front and not just used to bail out a team who are struggling to deliver.
Horizontal scope vs Vertical scope
Another similar example of abusing the MVP approach was given where the term MVP was used was as a justification for cutting corners in the implementation of features, for example bypassing some types of testing. For an MVP approach to work the features developed should still be of the same quality as a full release.
In the group the MVP approach has suffered from manipulation from both business and development teams and was widely seen as a great theory but rarely put into practice effectively.