The twisted concept of MVP and how it affects the quality of software deliveries
The twisted concept of MVP and how it affects the quality of software deliveries
A brief history of a software development squad
Once upon a time there was a software development squad formed by a P.O. (aka. Product Owner) and software engineers. On a beautiful day the P.O. brought to the team a great idea of a feature for the company’s platform. The MVP (aka. Minimum Viable Product) was defined and a super aggressive deadline too. The engineers started to develop it, and due to the aggressive deadline, they did not pay much attention to quality, but to the deadline. The most commented phrase within the team when someone questioned possible problems was “in the future we’ll come back to this with more time and fix what we need”.
The feature was launched and in fact it was a success, however, with several problems in production. Several customers complained about some problems, but the company measured only the numbers that suited it. An example that occurred is that the number of users that used the feature was really high, however, nobody noticed that the company’s NPS dropped due to problems with this feature. In this way, they validated that it was a success!
Shortly after the new feature in production, new bugs also came with it and the development team started making some patches to keep everything going even though it was not the best way to fix them. At the same time, new requests for changes related to this feature also came, but as everything was developed in a hurry, in addition to patches to fix bugs, these changes became increasingly complex and time consuming. One day, this scenario became unsustainable and they had to re-implement everything from scratch, generating a very high cost for the company.
Any similarity between this fictional story and the real world is purely coincidental. But if you’ve experienced something like this story, let’s understand a little better what happened and what could be different.
There are several possible causes that lead to problems like the one presented in our history, however, I will focus on a specific one that I consider super important.
The twisted concept of MVP
Definition of MVP by Eric Ries:
The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. [1]
According to the definition of MVP, at no time was it said that a minimum viable product is an implementation with bugs and made hastily with little attention to quality, right?
However, going deeper into this definition, I see that there is a big problem in interpreting the concept of MVP more specifically related to the term “least effort”.
How to interpret “least effort” in the MVP concept?
When creating a product or feature whose success is uncertain, there is no point in adding a massive engineering effort to support thousands of users at the same time. Or even create something that gives several configuration options, when I don’t know if anyone will at least see the value and use my product/feature minimally. That said, it is worth delivering something reasonably simple, that adds some value to my clients and that with the use of them I can extract feedbacks about what needs to be improved or added. This is very valuable and gives my team insights into what really matters investing energy and time.
To make it clearer what I’m trying to say, let’s make a comparison with the construction of a house.
If you have been in front of a construction site, you probably have seen a simple house that is built to store construction materials. That house will be destroyed at the end of the work. It is a temporary construction totally decoupled from the house and easy to remove to give support only during the construction of the house.
Another example that I would like to bring is when we paint a wall with various colors so that client can see how that room would look with each color. Yes, the wall will be painted again with the winning color, but there was a need to invest some energy and money to define the color.
Complementing with another example, it may be that the residents move to the house that has not yet been completed, as they cannot wait. So, in the kitchen, they already have the sink fully functional, but without any cabinets. The kitchen with only the sink already provides some value for them, even though it is not ideal, as they do not have cabinets to store the dishes. This is not to say that when they put the cabinets on they will need to destroy the sink and put it back on, it is something incremental that can be done without throwing away the previous work.
The example of the building materials house and the partial painting of the wall are examples of energy and resources spent that will be “thrown away”, but they are simple things that do not affect the budget, time and money in a way that makes the solution unfeasible. In fact, they may even avoid unnecessary larger expenses in the future. Thus, it is okay to build something relatively small that will be thrown away.
The kitchen example is something incremental. A feature that delivers value with basic things, but it is clear that it has not yet been finalized and can be improved incrementally.
Now following the same example as building the house, let’s assume that a structural wall was built in the middle of the room. A structural wall is a wall that, if removed, affects the structure of the house and can even bring it down. It is possible to make modifications, but it is clearly beyond the estimated budget, effort and time. It would be much better if, initially, they had planned the structural walls in more suitable places and not in the middle of the room. This will negatively impact air flow, people passing, lighting and decoration. Well, it is possible to make a window on that wall to mitigate the problem. However, in addition to not solving it at the root, it is a little weird to have a window in an internal wall of the room. This reminds me a lot of the patch that the development team was making in the story that I told at the beginning of this article. It may even be possible to remove the structural wall completely by moving it to another point in the house, but it will certainly be something that the team will need to stop the entire work and focus only on that for a long time. It is important to note that this will take a while and will not be as good compared to this structural wall having already been raised in the right place from the beginning.
Why structural errors occur and how to avoid them?
We could place the blame on the P.O. or on those who define and delegate demands and deadlines. But that is missing a basic principle of self-responsibility. Most of the time the person who sets the demands and deadlines is not a technician or with a background in computing. There is no way to expect him/her to know what is complex or to raise the non-functional requirements of such demand. It is up to the engineering team to list what needs to be done and how long it takes. Only with this information is it possible to negotiate scope and deadline. If engineers do not analyze the demand, they will have no arguments to discuss and define what is best for the team and the company. If the deadline is too tight for what needs to be done, the engineers who should explain it and try to reach a delivery agreement that is more realistic by cutting scope or adjusting the deadline. If you work or worked in a team that went through a situation similar to the story told at the beginning and did not exercise your power of argument, there is no point in complaining about the P.O., you were also wrong. And I’m not implying that only the technical leader or the most senior person on the team should do this. Everyone from the intern to the senior should have this autonomy.
I know that there are different realities in different companies and that it is not just about translating the technical to the non-technical and waiting for people to calmly accept a change in deadlines and scope. The point is that if you don’t do it, you are failing to do your part. You may not be able to negotiate any changes due to the various variables involved, but you need to do your best to at least have a clear conscience that you have done your part and exposed everything that should have been analyzed before any decision.
Conclusion
With the examples presented here, I tried to make it clearer how to interpret the definition of MVP and especially the term “least effort” in the context of MVP. I want to point out again that MVP is not synonymous with doing things in a hurry, and with low quality. On the contrary, it is delivering something super cohesive that delivers some value to customers and that can be increased and not thrown away and done again if the value of the product/feature is proven. In addition, I tried to make it clear that the responsibility for defining scope and deadline belongs to everyone on the team and not just the P.O. Technical inputs are very valuable for assertive decision making and the team’s engineers need to exercise this responsibility of exposing the possible problems of following a path, as well as showing paths that are more incrementally from a technical point of view, but at the same time add value to the business.
