Managing ExCom expectations around MVP in a global Agile organisational transformation
I've been brought in at fairly senior level to drive an Agile project transformation programme at a major international manufacturing organisation. In the infancy of their Agile journey, one thing that really surprises me is the haste with which people mention 'MVP - it's often the very first that they bring up (despite them having almost zero experience of Agile!).
"We're fixed on time, cost and quality, and totally flexible on scope. Now lets lock in an MVP and focus solely on that!"
To me, they're unknowingly fooling themselves as, with such focus put on MVP, they're trying to fix scope (without even realising it).
Whilst I try to understand what drove this focus on MVP, I'd love to hear your experiences around MVP and how you've handled this, the risks to watch out for, the difficult lessons you've learned - both for internally-delivered pieces of work, and partnered outsourced agreements (we have both). Saving Changes...
In my experience at least, a lot of the time a full Agile development doesn't usually take shape at first. They tend to focus on the MVP and move to agile after that.
So what they want is the smallest thing they need to get out to make it usable (so they say) and thus marketable and sellable. Or in my current role, fully replace the existing process in place with something that can be expanded and improved over time.
What happens a lot of time is that no one can agree on the MVP and you get scope creep. Now, of course in Agile, the scope is flexible, but that initial MVP should have a fixed scope. What makes the MVP should be defined. Now you can still break up the development into increments, but you still have to hit the scope of the MVP. That requires getting a firm definition of the MVP so you have a direction to go in. You may not need to know it all at once... but it is kind of helpful to help define what the MVP looks like, because you could find yourself constantly modifying it and never quite reaching the MVP. Once people realize the possibilities of what you are creating, they want it all in the beginning. Saving Changes...
I like Eric Ries's definition of it as being a method of getting maximum validated learning for the minimum investment. The challenge with coming up with good MVPs is that it is an art which doesn't come naturally to many Product Owners.
If the PO or product management team can't articulate what hypothesis or question they are trying to answer, then they don't have an MVP.
Get them to focus on coming up with the right question first...