Agile Episode II - What is Minimum Viable Product?

by Edward Kim

We last talked about the roots of Agile and how Agile thinking refocuses the efforts of a software development team on delivering real user value instead of following a plan (Agile Episode I). Our premise is that traditional PMP management methods, while well intentioned, often slow down development. This time we'll discuss Minimum Viable Product (MVP), a core element of Scrum and other Agile frameworks.

Imagine you are tasked with managing a construction effort that involves dry walling a room. If the room has four walls and each is 10' wide and 10' tall then it is pretty easy to nail down a fixed estimate for the entire dry wall project. After all, drywall is drywall and a room is a room. When there is little complexity and ambiguity, then a plan-driven approach with fixed requirements makes a whole lot of sense. Given a set of fixed requirements, we can schedule resources to meet a deadline with a high degree of confidence.

Thus we have our iron triangle of project management. There are requirements, time, and resources. To manage any type of project, we traditionally begin with fixed requirements and allow time and resources to flex in order to meet the requirements. And for a whole host of projects, this method works, especially in well understood projects like construction.

But what happens when we apply the same thinking in a complex and ambiguous environment?

Imagine now you are tasked with managing a software development effort to build a sales tracking tool for internal employees that provides customers with real-time order status. And the CIO wants a fixed price and timeline for both internal and customer facing features. At first glance, this list of requirements seems straightforward. So when the CIO asks for a budget and timeframe—the bottom half of the triangle against the fixed scope—one might be tempted to say something like "we built this before for a client and that took 6 months with 2 developers so we're confident with that same timeframe."

But here's the issue: anyone who has been part of even the simplest software effort knows that it is never as simple as it sounds. How many times has a product manager heard "four weeks, no problem," only to learn at the end of four weeks the team needs another four weeks? Managing to a plan against a fixed scope leads to these unfortunate situations.
Is there a better way?
Iron Triangle
In Agile frameworks, we flip the iron triangle on its head. Instead of locking in scope and allowing time and resources to fluctuate, we lock in resources, target a date, and deliver whatever we can as soon as we can. By focusing on value driven plans, we can ensure that users get pieces of functionality delivered at a promised date, even if the pieces aren't the whole vision of the product. So at the end of four weeks, instead of getting a request for another four weeks, the product owner can reasonably expect working software.

This idea of flexible scope is behind the Agile Minimum Viable Product. The MVP represents a subset of functionality that can be released and will deliver value to the users even though we know it's a partial set of the full functionality. So in our example sales tracking tool, perhaps the MVP is a system that can support basic order entry only—with an understanding that the customer facing pieces will come later on. Because the MVP is smaller and less complex, our estimates are. And if we cut up a whole project into a series of incremental releases, we'll continue to get better at estimating and building as we complete each increment. Even better, the product owner can start realizing ROI early on instead of waiting till the end.

Isn't a small set of valuable working features better than "we need another four weeks?"
© Copyright 1995-2021 - STOUT SYSTEMS DEVELOPMENT INC. - All Rights Reserved
envelopephone-handsetlaptop linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram