The Lean Startup philosophy of the Minimum Viable Product (MVP) relates directly to the Fundamentals of Agile Development. In this rapidly changing world, getting a Product to Market as swiftly as possible has become a priority. Speed is not just to beat the competition, but also to keep up with digital disruption. The Product has to be of Value to the consumer base. Product quality and understanding what the Customer requires is equally as important.
The MVP is an impressive name for a Stripped-Down Product. The MVP is a product that consists of only the Minimum Features needed by Stakeholders. This product is without any of the “Must-Have Features” that were requested up front but actually add little or no Value to the Product as a whole. Designing and explaining an MVP should likewise be the precursor for any successful Agile Development Project. This ensures that there is already alignment with the Customer expectations before the Project even begins.
Keep your Stakeholders Involved
Your Stakeholders and what they need are the reason for the Development in the first place. The Traditional product development method of collecting Requirements, going away for the entire Development Cycle, just to return when you desire Customers to Sign-Off, is no longer appropriate. This applies to all forms of product development Frameworks. These frameworks include “Customer-Driven Design”. These concepts do not always come from the Customer, often Concepts or prototypes are built first. These prototypes can then be promoted to gauge the response for the Market.
In Agile Development, it is Fundamental that Customers are included and dedicated to the Project, ideally every day. This is emphasized in the Agile Manifesto both as a Value and as a Principle. The Customers are co-opted from the Business for the duration of the Project. They can offer insights, assess what is delivered and agree on completion of the product.
Establishing a Minimum Viable Product
Keeping the Customer involved and engaged ensures that the Product being developed is Valued and will be utilized when released. What would make a Product Valuable, is that it is practical, with very little problems. It must fulfil the Customer expectations. The confidence level in the Product will also be high, as it is delivered Feature by Feature. The product takes shape throughout the Project and is not concealed behind a locked door which is only opened when the Product is complete.
Things Change
No matter how lean your Product is, or how brief the timeline to deliver, there will be Changes along the path. These can be for a variety of factors, for instance, an external incident in the Market which is a game-changer. Due to the momentum of the Project, there might be imperfect understanding of some of the Concepts at Project start. As the Project progresses, the Project understanding increases, and style, glitches or omissions may become obvious.
An Agile Project expects Change and will accommodate them according to the Framework utilized. For example, in Scrum a Change can only be applied between Sprints. The outcome of accommodating Change is that the end Product will be lined up to Customer requirements at the time of delivery, and not those at the start of the Project.
Minimum Viable Product Driven by Quality
An Agile Development Project attempts to be as proactive as possible. One of the mechanisms for achieving this is Test-Driven-Development, where the Test for the Software is completed before the Code is written. Naturally, the Test will fail, and Code is added until the Test passes. There are other versions of quality delivery, such as BDD (Behaviour-Driven Development), which operates in the same way, but focuses on the Requirements and ATDD (Acceptance Test-Driven Development). The effect of using such a technique reduces threat, error and revamp.
A winning Team
An Agile Development Project is driven by Teamwork. These Teams are fluid and Collaborative. It is critical that the Team is autonomous and empowered to make decisions. They should not be affected by hierarchical and autocratic decisions trickling down to them. Naturally there will be disputes and character clashes amongst Team members, aggravated by the pressure to deliver. These should be resolved amicably by the Team. During the Project, the Scrum Team (Scrum Master, Product Owner and Development Team) will build up and use knowledge gained. This ought to both accelerate the Project and supply a brand-new and improved baseline for the next Project.
It’s not a Perfect World
This all sounds wonderful, but reality has a nasty habit of interfering. While the objective is to design an MVP that can then be Developed in the Agile Project and democracy and Team Work is authorized, Politics and authority might impact the design, both at MVP and during Development Stages. As the Project progresses and the building blocks of the Product are delivered, it will become apparent that the Feature is not needed, especially if it is given low priority in the Product Backlog. Requesting additional input from subject matter professionals outside the Project can remedy this issue, without the Team Stakeholders losing face.