Monthly Archives: April 2015

MVP: The Zen of Software Development

Guest blogger, Toby Morris, is back with his take on the importance of Minimally Viable Product (MVP) in Agile.  Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak.  Enjoy!

When it comes to agile learning, development and growth, one concept rises to a level of importance few, if any other, concepts rise. With this one concept, if you grasp it, you will grasp the very heart of agile. If you can’t, you will struggle to reach the level of efficiency you should be able to reach.  Minimum Viable Product (MVP) is the soul, wit and zest of agile.

To me, agile is about maximizing the value and speed of delivery of the products my customers need and want. It’s about cutting waste and inefficiencies out of the development process. MVP is the deliverable with the absolute least number of features that will satisfy your customer’s needs. Period. Anything more or less isn’t good enough. Not enough features and the product may not be useable. Too many features and you’ve wasted resources and delayed getting the product to the people who need it most.

Minimum Viable Product is a concept that wraps up many agile principles, and it’s a tool for slicing through extraneous features. When looking at any user story, a first thought should be “how much of this is needed for a working product?”. Use the MVP blade to cut away at fluff and “wants” to get to the heart of the product. Try defining the product in a catalog blurb. If a feature isn’t in that blurb, then it’s probably not needed. Every feature that isn’t a core feature of a product is a wasted time in not only development, but also support.

Use the MVP blade to cut those extraneous features out of the current user story and add them to the backlog. If they are valuable, they will make it back into the sprint plan and into the product. If they never make it into a sprint plan, then they weren’t valuable. You just saved yourself, your company and your customer the time and resources that feature would have cost.

We’ve had customers at our company that ask for every possible feature during the early stages of a product’s development. They share a belief that if they don’t get everything in the first round, we’ll put features they want on the backlog, only to never find the time to get back to them. And that’s true. And that’s how it should be. If a feature belongs in the product, MVP will force you to include it. If it doesn’t belong in the product, MVP will relegate it to the backlog, where it will die a slow, cold death.

The Minimum Viable Product concept applies to anything you create. Anything you do. It’s the Zen of software development, and every other creative process. Whether you’re applying it to an entire application, a single feature of an application, or even a component of a feature, if you let it guide you, you will be surprised at how efficient you become.