When Focusing on Minimum Viable Product Is the Wrong Thing to Do
When Focusing on Minimum Viable Product Is the Wrong Thing to Do Agile
By Terry Bunio
There isn’t too many things more sacred than Minimum Viable Product in the Agile circles. Maybe Planning Poker, Automated Testing, and Continuous Integration. But usually Minimum Viable Product is also right up there. What if I told you that focusing on Minimum Viable Product is sometimes the wrong thing to do? Would I be branded a heretic?
Well it is – sometimes.
Client Focus
I sometimes find that we in the Agile community are falling into the old traps that haunted the traditional Software Development Professional – the fact that we know what is best for the client. I see comments like we shouldn’t create any documents or create any estimates because they are waste. Usually these positions are written from the point of view of the Software Development team. But we as developers may define value and waste differently than our clients. We need to understand the context of the project we are in and the situation the client is in and apply our processes accordingly.
For some clients not creating documents may be a waste as they will need to create them for regulatory purposes and it may take them longer to create them after. (In addition to being more error-prone) For some clients, estimates may provide them great value in their forecasting and budgeting process. So while we may think that creating estimates in wasteful, the clients may not share the same view. Ultimately, their viewpoint is the one that matters if we want to be client focused and remain in the service industry.
Our job as Software Development professionals is to provide our expert opinion and highlights the impacts of the decision to the client. If we can’t convince the client of the value of our position, then our position could not have been a strong one to start with.
Our job as Software Development Professionals to to provide all the information to the clients so they can make the most well-informed decision possible. Not to decide for them. Ever.
Minimum Viable Product
So where does that leave us with Minimum Viable Product? How could organizing the project in a way that you could go live during the project be wrong?
Well, what if going live early has no value to the client?
In the diagram above, what if the client definition of value is only realized by being able to transport a family of 5? Being able to structure a project to continue to deliver Minimum Viable Products comes with a cost. If you look at the example above, you can see that so each step up in the viable product chain, we need to swap out some frameworks and functionality for other frameworks and functionality. Structuring a project in this way doesn’t come without a cost.
Now there are many great technical reasons why to want to structure a project focusing on a chain of Minimum Viable Products. They help to address risk and provide lessons learned to improve the product and project as you go along. But don’t assume that it is always what the client wants, needs, or values. In exceptional circumstances, the extra effort to structure a project focusing on Minimum Viable Product may actually be most wasteful that structuring the project in a traditional way.
There might be a series of Minimum Viable Products that could be created to address technical risk, but not to provide any early client value. Perhaps it might be just one prototype early on to address new technology. The important thing is don’t assume it has value for the client.
Summary
We must always remind ourselves that the processes and methods we use must return more value for the client than other options and not just fall into the habit of executing every project using all the Agile tools in the tool belt.
After all, isn’t that what got us in the Detailed Work Breakdown Structure, Big Design Up Front mess before?
Terry Bunio is currently a Principal Consultant at Protegra. He has managed multiple complex projects and provided Project Management, Architecture and Database leadership for companies such as Manitoba Public Insurance, LPL Financial, Assante Asset Management, Moventum, Government of Manitoba, Investors Group, and London Life. More recently Terry’s focus and passion has been on managing Lean projects and being part of Lean and Agile Project teams. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical book agile and the real world approaches.
Protegra helps organizations in the private and public sectors identify and solve tough business performance challenges. Protegra offers management consulting services focused on operational efficiencies. For organizations that use information technology as a competitive advantage, Protegra offers software services development and solutions.
The idea that a company should create MVPs applies to startups, not to established companies. A startup, by definition, is a company in search of a viable business model. Startup and an established company are 2 totally different creatures. The former is not just a smaller version of the latter.
Contrary to the case you described (your company already knows, who its customers are and they are paying), a startup doesn’t know who its customers are, what problems they have and what solutions they are willing to pay for.
MVP is used to find this out. It’s an experiment, whose outcome will help locate the customers.
An established company already knows its customers and there is no need to work with MVPs like startups do.
> I see comments like we shouldn’t create any documents or
> create any estimates because they are waste.
To a person, who is good at creating MVPs, every company appears as a startup :)