I've been catching hints of MVx, with x being a variable, but am not finding a lot about it, online. In addition to Minimum Viable Products, are you implementing Minimum Viable...
- Experience
- Design
- Documentation
- Testing
- something else??? If so, what?
If you are, what are you doing and how are you implementing it?
Justus NScrum Master| BCBSTXArlington, Tx, United States
Yes, ever since the organization transitioned to be more product-centric, we have incorporated MVP to the initial deployment.
After the MVP deployment, there are additional deployments of capabilities based on feedback and learning(s) from the MVP. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Aaron. The word is new and was "created" by Ries when he write the best seller "Lean Startup". It is a best seller but it is nothing new inside it, most of those things has been taken from Lean and mainly from others "ancient" techniques used mainly in software. For example, about topics like this, the most solid work you can find is Poppendieck work "Lean Softwre Development". No matter is related to software it has been applied to other type of products. Returning to the point, and for giving you a real case, the technique was extensively used from lot of people when we do not have the opportunity to talk directly with the final user to know their needs about a product. That´s was most used when the internet "explode". A case where I had the opportunity to work with it was Google Gmail project. On times where I am writting MVP term has not been created. So, all the related things you stated are not valuable to be considered because the product and the need to mitigate the uncertainty on requirements are the drivers. Then, the use of it, is recommended in those type of situations. Because the organization I worked I was included in Ries trainning on the matter when the book was published. The Ries "theory" is aligened with those situations with a more general use: do not wait a lot to create a product. Create it, put it on the market and learn from people feedback. Saving Changes...
Aaron,
I use the concept regularly, but speaking as a former process SME/architect, remember that one person's process, document, test plan and procedure, etc. is another person's product.
Engineering in general has sometimes been called The Art of "Good Enough". Having experience in various disciplines of engineering and supporting functions, I've found that "good enough" is very subjective. I have had disagreements with stakeholders where my product of some kind effectively and efficiently met every single requirement, and was told that it was aesthetically awful. My set of aesthetics were clearly different than the people who found fault with my solution. Saving Changes...