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
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 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
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 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
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.