Agile, Agile Estimating, Project Management, Requirements, Software Development

When focusing on Minimum Viable Product is the wrong thing to do #Agile #MVP

mvp

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?

 

 

 

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

One thought on “When focusing on Minimum Viable Product is the wrong thing to do #Agile #MVP

  1. Great! I agree. It seems (like so much else) that the concept of MVP is misunderstood 🙂 And you manage to point that out. I wonder how many people actually have read the book The Lean Startup by Eric Ties?

    MVP is not a dev approach, it’s a business approach (or collaborative actually). MVP is about *learning* – *business* learning. What’s the minimum thing we need to do so we gain the learning we seek? What’s the minimum thing that will validate our hypothesis? Anything that doesn’t contribute to the learning biz seeks is waste.
    But it isn’t about the effort to create it. It can take several months to build an MVP. Although we should strive for getting it out there as quick as possible so we can try or ideas as soon as possible. We see a tendency of wanting to build something complete from the beginning (getting everything we can think of into the first release). MVP is about having a more scientific approach; make an experiment on idea, measure it, validate, learn, adjust, make another experiment. The Build-Measure-Learn feedback loop.

    Thus, if devs deliver something that business doesn’t learn anything from (validating their hypothesis) or can’t measure it (learn), it isn’t an MVP, it’s just an increment of an MVP.

    Posted by henebb | September 29, 2014, 5:55 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: