An MVP approach isn't a license for delivering poor quality.
Have you ever worked in an organisation where the pace of change is measured in geological terms? In your workplace, does the announcement of a new program of work lead to eyes rolling with disdain? Is there perennial disappointment, as projects always go over budget and take twice as long as initially predicted, and what is delivered is a fraction of what was promised, with underwhelming benefits and a plethora of manual workarounds. If this sounds familiar, then the promise of Agile is enough to bring joy to the hearts of the most cynical of corporate veterans. And it’s not just smoke and mirrors this time. Where organisations have got it right, their rate of innovation and momentum is nothing short of remarkable.
But, as with most things the devil is in the detail. It’s not just about handing out copies of The Lean StartUp, changing role titles, a bit of restructuring and sending the team on an Agile course. You can get the rhythm and mechanics going but still somehow irritate customers and internal stakeholders alike.
A couple of examples may help explain.
Every weekday morning my alarm goes off at 6am. I wake to hear the news delivered via a digital radio app through a wifi speaker. I love this technology but unfortunately, for the last few months, pretty much every other week (presumably at the end of the fortnightly sprint), my alarm has failed to go off. When the speaker manufacturer releases its latest system update it takes about 12-24 hours for all the speakers in our house to synch with all of the other apps and devices on our home network. So every second week I need a backup alarm. I’m not ruling out my own technical ineptitude as a possible root cause, but it’s easier to blame the manufacturer!
A second example came out of a conversation with a former colleague expressing frustration with a project team. A member of that team had been extolling the virtues of MVP and Fail Fast, recounting an idea that bore fruit within a matter of days, was put into production over the weekend but was backed out on the Monday when defects were discovered. What the project team member did not know was that backing out the change created over three months work for my former colleague’s team.
MVP was always about testing the minimum number of features with a market, to see if there was a viable proposition before sinking time, effort and extra cost into the product. It’s far better to realise you have a dud quickly, before you become too emotionally and financially committed. This makes absolute sense. But MVP is not an excuse for delivering features that don’t work. If you want to test for bugs, declare it a beta test. By moving to fortnightly release cycles all you are doing is making defects faster and irritating the customer more frequently in the process.
There is an additional, associated point here. One of the great benefits of Agile is that the marginal cost of change is now extraordinarily low. Many organisations allow customers to vote for new features and in a democratic world, where change costs very little, even changes with only modest numbers of likes and thumbs up (relative to the overall population of users) are put into production. All this change has to land somewhere and, in many cases despite the best efforts of the Human Centred Design practitioners, ends up as clutter. Comparing Facebook’s settings options today to what they were 7-8 years ago is a great example of this. For the customers who signed up to the simplicity and elegance of the proposition they are now faced with a bewildering array of features, the vast majority of which they are not interested in, do not understand and will never use. By pandering to the needs of the few – because it was not cost prohibitive – there is a potential to sacrifice the value to the many.
The lesson here is twofold:
Whatever change you do introduce, there’s no excuse for delivering poor quality.
Just because change is cheap to implement and requested by customers doesn’t always make it a good thing.
If you follow the methodology, in spirit and practice, I have no doubt both lessons are inherent in the approach. And this is why the first question to ask, before doing anything that may impact your customers is: “How does this add value to all our customers - not just the 40-50 that have voted for the new feature?”