Many organizations struggle to understand why agile isn’t working for them. Often, the most telling difference between a high-functioning, mature agile team and an immature one comes down to the understanding and practice of one key concept: the minimum viable product (MVP).
The struggle to appropriately define an MVP quickly results in a process more resembling “Scrummerfall” than agile. Teams have long release cycles, find it difficult to release a single complete story or feature, and subsequently outline months of work ahead of time in large project plans. This can lead to further process backsliding, such as “hardening sprints,” overplanning, or increasing sprint size to the point that you’re just doing small waterfalls.
The MVP brings tremendous value to a team’s ability to effectively implement agile practices. It also allows us to better understand what “value” actually means to our users and how context changes the meaning.
Your MVP must move through your validation and release cycles while still being valuable to your users. The shorter the cycles, the less time you spend refining the wrong solutions—and the more time you spend refining a solution that validates your hypotheses of the end users’ actual needs.
When defining your own MVP, your product should be the smallest set of features you can build that delivers customer value. We assume that the product will undergo a process of iterations after it has been released to the end users until it reaches a more desirable state. The concept of value is vital to understanding how to create an MVP: If a user wishes to travel quickly, a skateboard has far more value that one car tire.
Organizations that push back on adopting MVPs are often so risk-averse that they are unwilling to experiment and learn. They fail to understand that experimentation is key to agile.
They must understand that many apps we’ve built are not available anymore. Some were failures; others evolved into an entirely new product; others ended up being wildly successful. But the vast majority just simply didn’t make the cut. From that perspective, the only purpose these products served was knowledge discovery. We learned more about our users and the context in which they use our applications. We better understand their real problems and what they’re willing to pay to solve them. And we learned that specific assumptions we had were completely wrong, and others were spot on.
MVPs allow us to discover user context and what they value while investing little and accepting the least risk possible. They are small and releasable; they reduce the product strategy to its most fundamental elements and determine what features move the business forward the fastest. MVPs focus our attention, scope, and tools with a targeted depth to minimize wasteful work. Their short feedback cycles drive toward validated concepts that solve actual user problems and eventually solve bigger, hairier ones iteratively. It is through this repeated discipline that your agile practices will become even more valuable.
This blog is a repost from Techwell Insights.
