Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.
Thinking About MVPs… (No, not you Kevin Durant)
In Agile software development, we often rely on a concept called minimum viable product (MVP). The goal is to get a piece of working software in a customer’s hands as quickly as possible, so they can start to use it and provide feedback. Being part of a consulting services company, we are stewards on behalf of our customers budget and expectations working toward an MVP can be very helpful. Since MVP is a concept and not a concrete thing the process of defining and delivering an MVP can be challenging. It requires a strong, trusting working relationship between us and our customer to ensure we are building the right thing for them.
Here are some of the reasons I like MVP:
Shorter Time to User Feedback
The sooner we can have working software in my customer’s hands the sooner they can start using it to give feedback. Everyone is visual, and no amount of requirement and discussion can replace interaction with a UI. Often the feedback and direction a solution goes from actual usage and feedback can be entirely different than what originally envisioned on paper.
Option to Fail Early
Failure is never easy if given a choice. However, I would personally rather decide a marathon is not right for me in mile 1 and not at mile 20. At mile 1, I haven’t invested as much and so it’s easier to cut my losses. At mile 20 I may be inclined to push forward at all possible ill effects to my body because I’ve already invested so much. With an MVP a customer can easily decide if they want to continue with a product’s direction, stop or even regroup and go in another direction.
Baseline to Build a Roadmap
People often think that custom developed solutions are a once and done sort of proposition, but I look at all software applications a continuum. If there is the desire for an investment in improving and adding features to the solution, then it’s a good thing. If the solution isn’t being changed or people aren’t asking it to do more for them then it’s potentially a bad thing. With an MVP based approach, we can take feedback and feature requests and build out a roadmap that can fit the appropriate budget and timeline. A roadmap that is continually revisited through progressive iterations of the product.
Some thoughts on challenges with an MVP:
“I must have that…”
One of the most difficult challenges an MVP effort will face is determining what the minimum is. It’s a little like choosing a favorite child. There are lots of factors that contribute to the struggle to define a minimum. Crowdsourcing the product owner responsibilities so there is no single decision point and a mindset that if we don’t do it now, it’ll never get done are two I encounter often. Defining the minimum requires some hard decisions but ensure we don’t run 26 miles if we only needed to run 1. Delivering something that is too complex or has features users don’t want is worse than something too simple and in need or more features any day. It’s worse because it probably means you overspent and now must backtrack.
Bells and Whistles
Like the feeling that every requirement must be delivered in v1 the feeling is often that all the fancy bells and whistles need to be there too. My knee-jerk reaction when working on an MVP is that if you are worried about any eye candy during this time you are probably not focused on the right things or you aren’t building an MVP, you are somewhere beyond it. I like shiny things too, but I always try to catch myself during this phase to make sure the time is spent more on functionality.
Perfection
We all want anything we deliver to be as good as it can be but when striving to deliver something quickly and get feedback we will sometimes need to overlook imperfections. At ThreeWill when building an MVP, we still utilize a QA process to ensure our working software is tested by someone other than developers. In testing, we will likely identify issues and bugs that are of varying degrees of impact to users and importance to the customer. The key during this time is to make sure we focus and fix the things that have the most impact on either users or functionality but not necessarily focus on a goal of zero issues.
