Last week, I hosted a lunchtime round table discussion at the excellent event Digital Transformation: Delivering the Vision for Agile, Flexible and Secure Public Services. In addition to learning that a round table is a great alternative to trying to eat a buffet lunch whilst standing and balancing a plate, knife, fork and drinking glass, I also enjoyed the ensuing discussion.
The topic for the roundtable was The Destructive Myth of the MVP: Driving rapid ROI from Incremental Digital Change, which in turn was based on a blog by James Yoxall entitled, MVPs Can Be Dangerous.
The prime contention is that teams often focus too much on the Minimum Viable Product (MVP) at the outset of Agile projects, using it to define the scope of delivery – and that this constrains many of the benefits of the Agile approach.
Whilst the MVP can be a useful means of encouraging teams and stakeholders to understand and apply the concept of simplicity, what is more important is the incremental journey towards the MVP. The journey provides the opportunity for feedback and learning, and the potential to identify solutions that meet user needs in a simpler way than expected.
The initial discussion was lively and largely in agreement with the view that an MVP is a useful device but not an end in itself. If teams are to benefit from feedback and learning, and derive ongoing benefit beyond the initial deliverable, then any early negotiated MVP-based scope was dangerous. However, the group quickly diverged in a number of areas and it was clear that there were a number who had experienced behaviours that were common, counterproductive anti-patterns. Examples included:
- A delivery team that (incorrectly) regarded the MVP as the end goal with no opportunity for potential earlier delivery of value. As such, they organised the architecture of the MVP to optimise for technical delivery, rather than work incrementally to gain additional insight. This approach immediately removes any opportunity for feedback and learning, and obviates virtually all of the value from iterative delivery.
- Another went further and wrote a specification based on the MVP as a mechanism for managing scope and provide a contractual basis for a fixed-price project. Although there was limited opportunity to investigate this approach in detail it didn’t feel very Agile. Upfront design in this way leads to longer lead times before value is delivered, constrains feedback and learning, and reduces the opportunity to respond to change. It is possible to support contractual delegation of responsibility in an Agile context but ideally this should not constrain the value of the Agile approach. IndigoBlue’s Adapt 2.0® is designed to provide structured support in this area.
Other Agile anti-patterns included the implementation of modules as an 'incremental' approach to delivery, and views that, “It’s not possible to commit to a budget” when delivering incrementally. Incremental delivery should focus on value and this will invariably mean that high priority user stories cut across multiple modules (security for example seldom offers value on its own). IndigoBlue recommends the use of Solution Value Mapping to help teams focus on real value, and identify suitable incremental plans – please get in touch if you are seeking support in this area.
Unfortunately, lunch only lasted for an hour and we ran out of time long before the discussion reached its natural end and therefore we weren’t able to dig deeper into some of the areas. There were some excellent examples of projects where the incremental delivery path had led to significant changes in understanding and successful deliveries that reached beyond the original expectations for the MVP and ultimate 'final' deliverables. However, it was clear that there are plenty of opportunities to further optimise delivery through a clearer focus on incremental value.
The strawberry mousse was also excellent.