Minimum viable product
An interesting question on SE.SE got my attention recently. The question is about things that may happen to a project, in a context of a project which is targeted to be delivered eight months after its start. A discussion that followed showed that the notion of minimum viable product (MVP) may not be as clear as it should be. This article attempts to clarify it.
A bit of background. Over the years, I worked on projects that used Waterfall, and the ones that used Agile, and everything in the middle, such as, you know, when you claim you're fully Agile, but your sprint is three months long. The obvious difference between all those projects is the frequency of deliveries, the focus on how regularly the chunks of the project are delivered to the customer—not just shown, but actually delivered to production. Although not the same as time-to-market (TTM), the frequence of those interactions has a direct effect on TTM: if you have two deliveries per year, your maximum TTM is more than six months. If you're doing several deployments per day, your TTM could be as short as a few hours (although in general, it is much longer, due to all the processes that happen before the development of a given feature starts).
While both TTM and the frequency of deliveries are important, there are also two other metrics which are crucial as well, but often forgotten: the time before the first delivery, and the time before the MVP.
The first deals with a simple “Hello World” which ends up in production. This is a crucial step, in three ways:
Only after this step is finished the team can know that the project can be delivered. As surprising as it could sound, there are projects which are developed for months or even years, and only when they are considered finished by the programmers, the ops are asked to make it work in production. More often than not, what happens is that the ops find things that won't work, and start claiming that developers didn't do a great job; the developers claim that the project works on their machines, and it's the ops fault to be unable to make it work on the servers. Eventually, the project is released months later, and some projects never get released.
It puts the developers on a good track, knowing that any change they do can end up in production and be seen by the stakeholders. This means that the team has a continuous integration (or continuous delivery) pipeline all set, and that if something does work locally, but not in production, it will be quickly discovered either by the tests, or by the stakeholders. Also important is the fact that they are conscious that the project should be buildable and runnable at all times, which prevents large changes which break mostly everything and jeopardize the project.
It increases the stakeholders' confidence in the project. They can see the concerte result of the work of the persons they pay, as opposed to something which is somewhere on the machines of individual programmers.
The second, the MVP, is as crucial as the first one. A “Hello World” is great, but it has no business value. The MVP, however, while missing a lot of features the stakeholders may want, is still producing some value. From the moment the MVP is released, there are two interesting effects:
The confidence of stakeholders increase even more. Essentially, they can now decide to stop the project, and it will still bring value to the business.
The business may decide to enlist some persons to start using the application. Maybe as beta testers, or maybe as ordinary users. Those users, in turn, provide valuable information about how they use the system, and what are their needs, which in turn helps prioritizing the changes.
Unfortunately, more often than not, businesses don't understand the value of regular deliveries, TTM, first delivery and MVP. Some projects are developed as a black box: the business thrusts the requirements and an arbitrary deadline at the team, then completely forgets about the project, and starts asking questions only when the deadline is close. While this is how projects were usually managed thirty years ago, it's not the right way to manage them, and it brings all sort of problems, which is illustrated by many, many phenomenal failures in the IT industry.
One of the problems is that businesses usually believe that an MVP is the same as the fully-featured product. “Nice to have” features are then considered as something essential, without which the product cannot go live. I wouldn't explain in this article why this happens, but when it happens, it is indicative of a badly managed project, with incorrect interactions between the team and the stakeholders.
Instead, an MVP is simply something that can bring value on its own, and just that. It is usually far from ideal, but it can be successfully used to attract customers and bring money. When a project is a fruit of evolution, as it should be in Agile, MVP becomes quite clear, thanks to two of its aspects: the prioritization and the regular deliveries. The fact that the features are prioritized by the business means that the developers work first on the most valuable features. The fact that the changes are delivered regularly to the stakeholders means that those stakeholders see a concrete result, and can guess when what they see can be used as an actual product.
Let me illustrate what the MVP is all about through a few examples.
An e-commerce website
Long time ago, I was working on a very specific e-commerce website. A company was selling the automobile parts to their partners—the other companies, obviously. Their legacy process involved salesmen calling the partners and agreeing on the specific orders by phone. This was a huge waste of time, and so they wanted to lower the cost of the process through the World Wide Web.
In order to do that, one needed to:
- Connect to the corporate LDAP in order to enable the customers to login to the website.
- Show the products by categories, with their description, price, etc.
- Allow the customers to add those products to a cart, and to confirm their order.
The customer had a lot more in mind, but it appeared that those three features were enough for the basic needs. You may note that there was no question of registration of new customers (a feature which was quite challenging to do in terms of security, involving write permissions to LDAP), or even online paying (also challenging because of a series of constraints), or an administration part which would allow someone from the company to modify the products or check the analytics. All that was nice to have, but wasn't part of the MVP. The ability to deliver the MVP in a very short amount of time was a huge benefit for the stakeholder, since it allowed the company to drastically reduce the time the salesmen spent on the phone. Moreover, it costed nearly nothing in terms of the cost of software development.
An ETL instead of an overly-complicated system
A year ago, a colleague asked me for advice. He was asked to work on a new project which was collecting data from a lot of databases and APIs, and aggregating it, in order to generate the reports. The original project specification was four hundred pages long, and the project was expected to be done in one year by a team of five developers.
The colleague was asking how I would approach the problem from the perspective of architecture. We tried to model it as an ETL, and it worked well. Then, I talked to him about the importance of prioritizing the features. He talked in turn to the business, and was so convincing, that this was the first Agile project done by the company.
Originally, the idea was to do everything from scratch. What they did, instead, is to grab an existent ETL, with an interface which was simple enough to be used by businesspersons to enhance the transform step of the ETL, or even add new sources of data. This reduced tremendously the complexity and the cost of the project. They got their priorities right, and two months after the project started, the MVP was delivered. The business was amazed at how much value it brings, and how flexible it was compared to the original concept. The team (of three persons instead of the originally expected five) was asked to do a few enhancements, and worked for three additional months. Then, the project was considered a huge success; it was also the only project, among hundreds of other internal IT projects, which was not late.
Who needs a database, when there are text files?
For my personal needs, I start a lot of personal projects. Some end up being valuable tools that I use for years. Others are abandoned. Until a few years ago, a new project which had persistence in it usually meant that I would deploy a new database. But more recently, I stopped doing that. When I need to store information, I use plain text files on an NFS share.
Technically speaking, that's not a great long-term solution. Performance is a concern. Concurrent access could cause a lot of trouble. Security is questionable. That's obviously not the solution you would think about for production machines. Nevertheless, the solution appeared to work quite well for a few projects.
One project is an API which stores values from the sensors. By storing the data plain-text in the files, I can postpone the decision of a type of database until the moment where I would have enough insight to understand how much data there would be. Right now, I have no idea if I need to use Elasticsearch, or InfluxDB, or something else. A few months later, I would possibly have a better idea.
What is also important is that by sticking with the most simple storage solution, I can deliver the MVP in a matter of days or sometimes hours, start using it, and focus on other projects. Unlike a prototype, though, those projects weren't throw-away code: the persistence layer was clearly separated from the remaining application, in order to swap the current mechanism with a database later on.
Conclusion
Working for customers, it's not always easy to explain them the difference between an MVP and a fully-featured product. Those who haven't used Agile or used it wrong imagine that the very first release should contain all the features they imagined. This, often, results in low customer satisfaction, delays and missed deadlines, feature creep, and cancelled projects. Therefore, great care should be taken to ensure the stakeholders understand what an MVP is, and why is it important.