The MVP of Agile

When you think of the world before Y2K, visions of Saved By The Bell, Good Will Hunting, Will Smith's “Gettin' Jiggy Wit It', and 2 year waterfall-based projects come flying into the mind.

2 years you say...I must have heard you incorrectly. Did you just say that projects would take 2 years to deploy? That just couldn't be! How soon we forget...

Back in those days you'd spend 4 months writing requirements, followed by 6 months designing a solution, followed by 8 months developing/testing the product, followed by 1 month preparing/deploying the application.

After deploying you'd find out that:

1. There was no longer the business use case/need for the solution OR

2. Others had beaten you to the punch and now you were just a follower OR

3. Your customers hate it and you have to make dramatic modifications (even worse)

What a depressing landscape! And after all that time and effort!

Over the last 10-20 years, agile has been all the rage in application delivery - people touting the short-cycle feedback mechanisms and regular opportunities for modification. This created a product that evolves in parallel with the changing needs of both internal and external users. What's not to love about delivering a product that you know is on-point from both a business need and end user expectation perspective?

Some are drawn to the Agile approach based on the flexibility of execution, whether it's Disciplined Agile, Feature-Driven Agile, or Kanban, there seems to be a flavor for everyone. While this sounds perfect, there are situations where even this flexible structure can take a considerable amount of time to deploy. We'll dig into arguably the most critical in this article – not formally defining a MVP solution.

Defining a MVP (minimally viable product) solution is an extremely powerful tool when it comes to Agile delivery; it focuses the team on a common goal, and provides the ability for swift decision making – the functionality is either part of the identified MVP solution or it's not. If not, put the story in the backlog and it can be tackled after the MVP solution is deployed.

This is extremely important for a couple reasons:

• Staying true to your MVP definition allows for an accelerated timeline deploying to Production. Once deployed end users will provide invaluable feedback for your product. Prototyping/control testing can only provide so much visibility – nothing beats feedback from real end users.

• If you don't have a MVP guidelines, everything could 'possibly be part of the solution', resulting in many blue sky conversations that are detrimental to the overall timeline. The focus on what is 'in' or 'out' isn't there when those lines aren't drawn.

Without a MVP solution, the SDLC built around those short cycle feedback mechanisms can gradually continue to drag and extend the timeline. Instead of clean, short duration deployments (ideally in the 1-3 month time period), you end up with projects that could be 1 year + without exposure to those high value end users.

This is sounding familiar, but I can't put my finger on what it reminds me of...arg. Old age must be getting to me. 

Ah! It reminds me of waterfall! Make sure you're getting the most out of Agile and ensure a MVP solution is defined from the start. 

Here is one article that I think provides a great approach to defining a MVP product, especially if you haven't done so in the past:

MVP with Story Mapping