All Blog Posts

What Is an MVP and Why Is it Crucial for Agile Software Development?

MVP Cadillac Concept

If you ran a non-agile company and one of your biggest clients came to you asking you to build them something equivalent to a Cadillac, what would you do?

Well, you’d likely start planning: You’d interview the client’s team members to learn more about the specs (engine, seating, color, number of doors, and so on), find suppliers, build, test, build some more, and then test again. After more than 18 months, you’d be ready to show off all your hard work in the form of the Cadillac the client requested.

The only problem?

They don’t like it. It’s been 18 months and the market has changed. The big 4-door car with the 8-cylinder engine isn’t in demand anymore. People want smaller, more efficient transportation. So, the requirements changed. Where does that leave you?

With 18 months’ worth of wasted work and an unhappy client, that’s where. Can this situation be avoided?

Learn more about the Cadillac concept. 

MVP (Minimum Viable Product), the Core of the Agile Methodology

An MVP is a concept from agile scrum that refers to a product that has just enough features to satisfy the needs of early customers and, more importantly, give them something to provide feedback on to shape the future of the product.

The real value of an MVP lies in the learning opportunities it provides. Instead of jumping the gun and creating all the features you think users want in a single iteration (a process that’s lengthy and prone to errors), you do it in “sprints” or stages and you learn as you go.

Let’s go back to the Cadillac example above. If your customer asks for a car, what can you do to shorten the development process?

First off, start by asking what they need. As in what they REALLY need. Why do they want the Cadillac? They need transportation, right?

According to the agile/scrum methodology, your MVP should be the first product that satisfies the transportation need. In this case, that could be a bike. It’s not fast, it’s not ideal, but it starts to take care of the problem.

Next, as you identify pedaling as the users’ main frustration with the bike, you can upgrade it to a motorcycle. And, as you keep learning about transportation means, you can finally build the car—maybe starting with a Honda and working your way up.

The advantages of starting with MVPs via the agile approach include:

  • Speed to Launch: A bike takes much less time to design and build.
  • Flexibility: While you work toward the final product, the client has something to use and test.
  • Better Products: As you keep working on your final product, you learn more about your client’s expectations in real time, so you reduce the chances of building something that no one wants.

Building cars is not exactly our area of expertise, but it’s an easy-to-understand analogy for many people. Henrik Kniberg did an excellent job of explaining this analogy and using it to demonstrate the value of starting as simply as possible and developing in iterations. 

What we really know is software development. So let’s take a look at how the agile process and the MVP concept can be applied to software development by using a hypothetical project.

Building a Custom Software System?

Learn the benefits of outsourcing to an experienced software development partner.


Building a Custom Platform — Start With the MVP 

Meet Medical Clinic X, an organization made up for the purposes of this anecdote. It runs several mobile units that provide basic medical services in remote communities and urban areas where access to medical services is difficult or restricted. Many of its patients don't have or are reluctant to use forms of ID, don't have a permanent residence, and have difficulty obtaining prescription medicines. 

Medical Clinic X found that none of the existing electronic health record (EHR) platforms allowed the providers to efficiently keep records of such patients and the treatments they'd been prescribed. They needed a custom solution and decided it would be better to develop one from scratch that they could then further customize as their needs evolve, rather than extend an existing solution.

If Medical Clinic X contacted Far Reach looking for a custom EHR, here’s (at a very high level) how we’d structure the project. First, we’d work with the Medical Clinic X team and providers to understand the highest priority needs and overall goals. 

Based on that research, we’d map out a backlog for an MVP (aka the bike) that focuses on the most urgent pain paints. This hypothetical MVP would integrate a variety of patient identification methods for enrollment purposes and would otherwise have only basic features for keeping patient records: Who that patient was, when they came to the clinic, what problems they had, and what treatment, if any, was prescribed. 

After the MVP was rolled out, we would continue working down the feature priority list, building new functionality as we were learning from and improving the system based on its real-world implementation. 

By taking this approach and getting something into the hands of the client, we would learn more quickly what worked well and what didn’t. The client could start utilizing the platform and its high-priority features as lower-priority functionality was built out to turn the “bike” into a motorcycle, a car, and eventually a Cadillac. 

Wrapping Things Up

Custom software development takes time. During that time, market demands can change—so can the needs of the client. The agile approach helps us build a product that’s adaptable, scalable, and meets the users’ needs as they evolve.

Want to discuss this further or have questions about MVP and agile development? Reach out!

Curious about the terms we used in this post? Demystify our nerd-speak.