When adopting Agile at scale, we always need to remember the three things that have the most impact… Context, Context, and Context.
MVP or Minimum Viable Product is a fantastic idea for start ups. It tells you to build the smallest, most minimal product that will be viable for your target customer segment or market. MVP is about discovering a market for a new product. Interestingly many people miss the important aspect of MVPs. MVPs are a risk management approach to help you determine whether your hypotheses about your target customer segment and their needs (or jobs to be done) are correct or not. MVPs are nothing to do with your product really. They are to do with the customer segment and their needs. A start up is defined as a organisation that is establishing its customer segment and the customer’s needs.
Normally when we talk about scaling Agile, we are talking about introducing Agile to an organisation with established products and markets. And this is the problem. These companies already have customers. These companies already have market share. These companies already have products that are more than minimally viable. As they engage in an Agile transformation, they adopt Agile, Lean, Lean UX and Lean Startup concepts… including MVP. However they already have a product so they assume that MVP means the MVR or “Minimum Viable Rewrite” as they transform to Agile and completely replace existing products with “Agile” products. MVP becomes the minimum amount of the existing product that needs to be recreated in the new “Agile” product. That minimum tends to be a complete rewrite of the existing product. In other words, a completely non Agile approach to transformation.
Over the past few years I have seen a pattern emerging in organisations that have mature products as they adopt Agile. They all have a flagship Agile project that has a scarily familiar description. They have successfully implemented “Scrum” (This is in no way a criticism of Scrum because they are not really doing Scrum). They proudly tell everyone about their two week sprints and monthly/bi-monthly releases. The problem is that the releases are always into a “testing” / “staging” / “pseudo production” environment. The flagship project normally has one or two years worth of inventory in the non production environment and they are about to release a huge change on the business. The only risk this approach addresses is the risk that “IT” will deliver into that environment. There is no feedback from the market that the rewrite product is fit for purpose. In effect the risk that the business case (understanding of the target market’s needs) is wrong or the damage to the existing product (market share) are ignored.
The alternative for organisations with mature products is to consider an MVI or Minimum Viable Investment approach. First instrument up your product so that you understand your current metrics. Then identify investments into your product to improve it. Gradually make small investments into your product until you can make big architectural changes easily. In effect you refactor your product towards a new vision of the product.Start from the outside and work your way in. In other words, start with your customer and work back through the value stream. Understand that taking an inside-out approach will lead to a massive and risky transformation that ignores your customer.
Transform your approach to your product rather than try to transform your product itself. Transforming your product is normally a good indicator that you have not transformed your approach and thinking. It is big batch change.
If you are building a new product for a new market, use an MVP approach.
If you have an existing product (i.e. market), adopt an MVI approach.
If your transformation partner (consultancy) is advocating a big bang approach to transformation, sack them. They do not understand Agile and should be cast out and shunned for selling snake oil. Obviously they wont say its a big bang approach, but measure the lead time to production customers. Let the data reveal reality rather than opinions.
March 26th, 2016 at 11:00 am
Interesting. We’ve been using the term ‘MSP’ – minimal *sustainable* product for quite some time to emphasise the difference between a product or service built for marketing testing vs. one that can be run as BAU. There can be quite a delta as operational concerns (security, performance etc.) can be descoped under the banner of ‘minimal’ – where ‘minimal’ has a features-only emphasis.
I can confirm your observation that many ‘MVP’ initiatives are like-for-like (and more!) replacements for existing systems rather than focused value-based investments. Establishing a baseline from the current state as a basis to measure investment effectiveness is good advice +1
March 26th, 2016 at 1:03 pm
Oh my gosh, so very “yes” to this. Heard this conversation over and over again in agencies:
Client: I have an old site that does X, Y & Z. Please make it better.
Agency: We want to be Agile. Let’s talk about MVP & what the 1st iteration will do… 😣
When a client has a mature offering and/or an established customer base, you just can’t get away with releasing a new version of their “thing” that does significantly less or different things to their old offering. And if you’re then suggesting a 12 month roadmap (plus associated £££s, naturally) just to get back up to feature parity, you’re doing it wrong.
In fairness, clients also need to understand this model. I’ve worked with a few clients who want to replatform an established ecommerce site with years of organic growth and feature additions onto an out of the box solution, on the premise that the OOB offering will get them (back) to market super-quick. Sadly, when you start discussing the OOB feature set and the time & money to redesign and redevelop all the extras, they typically get a bit upset and confused: “what do you mean we can’t carry across our loyalty points program? What do you mean the solution doesn’t include in-store collection?” etc
March 29th, 2016 at 8:44 am
What about taking the MVP approach with your developments teams and your customers as an end users? So if your development team is your end user of the codebase, they say ok we can’t work with it anymore, we need it to be fixed to be more productive. Then iteratively you make your codebase more and more fit for purpose, by refactoring bit by bit, at the same time you can fit in some small features for your real customers. This way MVP still stands.
March 29th, 2016 at 9:04 am
I love it. This was actually going to be my next blog post.
Think strategic. Deliver tactically (iteratively)
March 30th, 2016 at 3:15 pm
[…] este acrônimo pela primeira vez ao ler um post do Chris Matts (original em inglês, aqui). De forma sucinta, ele quer dizer que empresas estabelecidas, com clientes conhecidos e […]
March 30th, 2016 at 3:35 pm
Interesting perspective you bring up.
At my current workplace, we use MVP for existing and new products but the equivalent of your MVI is usually not part of the MVP.
Basically, we misuse the term MVP, for a sub-set of core/critical features for our end-user (or internal user) on existing or new products. Something we can release and validate our hypothesis either internally or to the market, always generating value. Depending on the context, we use MVP for different purposes and meanings, which generate a lot of confusion internally.
Our MVIs (we don’t use any acronym for it) either belong to a reactive project to try to fix things (often too late and being more expensive then it should) or are approached in advance by a support/mantain “lane”.
April 21st, 2016 at 2:52 pm
[…] Transforming an existing product is hard. Transforming the approach to building the product is easier. This is where MVI comes into play. Might this idea be applicable to your situation? You can view the original post here: https://theitriskmanager.wordpress.com/2016/03/26/mvp-considered-harmful-introducing-the-mvi/ […]
August 21st, 2016 at 7:29 am
[…] Owners often struggle to make stories small enough. Agile projects end up with “MVP”s that take the team months to build. The solution to this problem is to slice value rather than […]