When deciding how to structure development of a new application we are faced with a series of tough decisions. Do we start by making a user study? Do we prepare a series of graphic designs to show the client? Do we dive right into writing code? This is not a new problem and many solutions have been proposed, often heavily influenced by the background of the person or organization behind the proposal.
Maybe no perfect solution exists or at the very least it depends on the project, customer and expectations involved. Over the years we have tried many different approaches with varied success. One key factor in determining how to approach the project is the mindset of the customer and how tech-savvy he or she is. It may, for example, be almost impossible to convey an idea of the end result through wire frames to someone not used to thinking in abstractions and imagining the result beyond the lines and boxes. It is the identical problem architects often face and try to solve by creating elaborate 3D models to convince their clients. On the other hand, if you start with graphic design before deciding upon system architecture and before having a clear idea of what kind of problems you will need to solve, you risk designing elements that aren’t needed or will change. This seems a lot like the tail wagging the dog.
So, given that both the customer and the development team are on the same page, what is the ideal way of approaching a new software project? As we have written about in the past, the Ruby on Rails team here at Intesys believes strongly in taking an Agile approach to software development. With this is mind we are convinced that software development needs to be driven by value. Any time spent on something that doesn’t bring value to the end product is waste that we try to eliminate as much as possible. A first step using this approach is to reach a Minimum Viable Product (MVP).
Minimum Viable Product (MVP)
A Minimum Viable Product (or Maximum Value Product as we like to call it) is exactly what it sounds like. Take a word processor for instance. What is the MVP in this context? We need a way to create a new document, open an existing one and to save our modifications. Do we need bold and italic text? Do we need mathematical formulas or the possibility to insert images? They are all nice features but not essential in order to have a useful product. On the other hand, a word processor that allows you to insert images and mathematical formulas but not to save your work would be almost completely useless. This simple example highlights the importance of always focusing energy on what brings most value to the product at any given time.
MVP Evolution – Avoiding Waste
Often times an MVP is considered a throw-away proof of concept that you quickly throw together in order to learn more about your product and how it will be used so you can learn valuable lessons before starting with the “real” development. We agree that an MVP is an excellent way of getting a lot of value with low risk but disagree with the idea that the result is a throw-away prototype.
Like mentioned above we try our best to eliminate waste from the development process wherever we can. Treating an MVP as a throw-away prototype goes against this principle. Fortunately, with a well-built Ruby on Rails MVP and Agile practices, it isn’t necessary to throw away anything and instead we build upon the initial work, turning into a more evolved product.
We think that the idea of treating an MVP as something expendable has several explanations. Many companies have large and complex systems built with technologies and frameworks that aren’t conducive to quick, experimental and, incremental development. In these cases it’s common to use a more flexible framework, such as Ruby on Rails, to quickly develop a prototype that, if successful, gets rewritten using whichever framework the company has invested in. Another reason is the case when a company decides to implement a prototype using their existing, unsuited for agile development, framework. Often times the cost of change in such systems is great leading to the choice of throwing away the prototype and starting from scratch.
It’s interesting to note that this cost of change isn’t directly related to prototyping itself but rather to the inflexibilities of the technology and frameworks involved. So, if prototyping causes you to want to start over from scratch, what’s preventing this problem during the rest of (even more complex) development?
We have found that using Ruby on Rails (and solid software development principles) allows us a seamless transition from prototype to product with minimum waste along the way.
Only for Startups?
A common misconception is that MVPs are useful only to startups needing to quickly get up and running. MVPs are all about eliminating risk by finding problems and removing waste as early as possible and it’s easy to see that this is just as valuable (if not more) for large established businesses.
As hinted to above, a reason for believing MVPs are only for startups may be that established organizations often have systems that make rapid development difficult and no possibility of changing these systems. We realize this and, although we prefer to transition seamlessly from idea to prototype to product, we think that MVPs offer enough value for them to be used as expendables, developed using rapid methods and frameworks, in these situations.
Conclusion
- An MVP is a valuable tool since it allows you to eliminate risk and waste early in a product’s life-cycle – where it counts the most.
- Ideally, choosing the right technology, you should be able to transition from idea to prototype to product with practically no waste on the way.
- Even in cases where the MVP is treated as a throw-away prototype, it’s value justifies the effort of making it.
In our experience, Ruby on Rails is an excellent framework for rapid prototyping meeting all the criteria needed in order to maintain flexibility while adding value to the end product during the whole process.
If you are interested in MVPs and what we do here at Intesys, please don’t hesitate to contact us. We would like to discuss what we can offer you and your business!
I deeply agree with most of your opinions. Often is the project’s nature and its type that makes the difference on deciding the right approach. Secondary but sometimes it become the primary not all technologies are well accepted from the all IT departments… and so the customer needs and extra time to face, understand and digest different technologies; and finally the related advantages adopting a new one