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<\/a> 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\u2019t needed or will change. This seems a lot like the tail wagging the dog.<\/span><\/p>\n 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 <\/span>Ruby on Rails team here at Intesys<\/span><\/a> believes strongly in taking an <\/span>Agile approach to software development<\/span><\/a>. With this is mind we are convinced that software development needs to be driven by value. Any time spent on something that doesn\u2019t 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).<\/span><\/p>\n 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<\/strong> at any given time.<\/span><\/p>\n 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 \u201creal\u201d development. We agree that an MVP is an excellent way of getting a lot of value with low risk<\/strong> but disagree with the idea that the result is a throw-away prototype.<\/span><\/p>\n 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,\u00a0with a well-built Ruby on Rails MVP and Agile practices, it isn\u2019t necessary to throw away anything and instead we build upon the initial work, turning into a more evolved product<\/strong>.<\/span><\/p>\n 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\u2019t conducive to quick, experimental and, incremental development. In these cases it\u2019s 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.<\/span><\/p>\n It\u2019s interesting to note that this cost of change isn\u2019t 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\u2019s preventing this problem during the rest of (even more complex) development?<\/span><\/p>\n 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.<\/span><\/p>\n 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<\/strong> and it\u2019s easy to see that this is just as valuable (if not more) for large established businesses.<\/span><\/p>\n 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.<\/span><\/p>\nMinimum Viable Product (MVP)<\/span><\/h2>\n
MVP Evolution – Avoiding Waste<\/span><\/h2>\n
Only for Startups?<\/span><\/h2>\n
Conclusion<\/span><\/h2>\n