In a previous post I covered the concept of minimum viable product (MVP) as a means of  supporting learning and validation of ideas during product development. To complete the picture I would now like to address the concept of minimal marketable product (MMP), which is a version of the product that is just sufficient to go to market with. On the one hand, MVP is used to validate whether you’re on the right path in creating a product that is valuable for users while reducing the risk of failure and waste; MMP is, on the other hand, aimed at achieving short time-to-market while delivering the right functionality to provide value to customers.

Many Agile projects still stick to working towards deadlines instead of iterating and building product increments. When working towards a deadline, building feature after feature per iteration, the benefits that one would normally have with an incremental way of working, such as learning about users, market, technology, and architecture are lost. The risk of waste is taken for granted in that case. Nevertheless the agile manifesto is violated on several points such as simplicity or delivering valuable software to users.

There is always a debate regarding the ideal size for a scrum team. The scrum guide recommends seven members plus two or minus two as the ideal number. There seems no consensus among the agile community regarding what the best size of a team may be. However, one issue that people are in agreement with is that smaller teams are more functional and productive. A quote from the scrum guide states that “small enough to remain nimble and large enough to complete significant work within a Sprint” The question then is, how small is small? This will depend on a number of factors.

A major challenge faced in product development, especially with newly introduced products, is to validate whether or not the product solves problems and delivers value to it’s target group. It is common practice to develop products based on assumptions without involvement of real users. As a consequence the risks of failure and waste of costs is accepted. Even expensive market analysis cannot eliminate uncertainty about the product’s value to real users. Obtaining valid feedback and learn from a product that doesn’t exist yet can be difficult, which leads to a high degree of uncertainty in terms of features the product should contain. Why would you take that risks while real users are available to support you gathering insights and validate the product? The …

Product Development powered by Minimal Viable Product Read more »

Individuals and Interactions over Processes and Tools. This statement is part of the agile manifesto. It highlights the importance of people and communication within the project. The key to understanding this statement is understanding the meaning of the word over. It may seem simple yet many people get it wrong. The word over is repeated four times in the Agile manifesto. The word over in this context means that while processes and tools are important in software development, individuals and interactions are more valued. This doesn’t mean we do away with the tools and processes. Actually we cannot work without them, but we should put more emphasis on the people and effective communication rather than following rigid processes. Developers love …

Unfold The Agile Manifesto – Part 2 Read more »