Would you consider a single-MVP project as agile?

A colleague of mine recently mentioned about his team being stressed with their agile project. Somewhere during our discussion he mentioned that they were planning to have just a single MVP or release. That's when I started wondering if a single-release agile project could be a paradox!

If you are planning just a single release, you might have already rejected the concept of a prioritized backlog. If all items in the backlog need to be released together, what is the whole point of priority - you need to release everything anyway! When the notion of priority is removed, the biggest casualty is the team since the overwhelming weight of "there is so much to do and so little time" starts bogging them down.

Why use MVPs

The fundamental driver for the concept of time box is to establish focus on a smaller subset of the backlog based on priority. The sprint is a more common example of a time box where we use focus to drive progress. I consider MVPs to be a vague form of time box at the macro level, because there is often a release date attached to it. On a side note, if you haven't yet planned a release date for your next release, I believe you are just avoiding decision making with respect to priority.

Apart from being able to focus on items that are most valuable to the business, MVPs could provide more benefits:

1. A release date always creates a sense of urgency within teams. This, combined with having a focused set of work in progress, is often a good recipe for sustainable optimal velocity.
2. For greenfield projects, smaller multiple releases help create release cadence by ironing out integration issues early on. They also assist in enabling improvements to the delivery pipeline (automated or otherwise).
3. Opportunities to space out bug fixes across multiple releases based on actual severity and impact. This could help focus on features while removing minor bugs from scope.

Are all single-release projects doomed to fail?

Not necessarily! I have had teams which have delivered the entire backlog with a single release! In retrospective, we always had very ideal conditions like

• a manageable backlog, so we knew we could do it
• sufficient time and clarity upfront, therefore, we weren't waiting
• an established release pipeline, so we didn't have integration complexities
• we had done similar work before, so we knew how to build in quality and prevent defects

The challenge, therefore, could be more with greenfield or complex projects where there are lot of unknowns:

• The backlog is already too big to be delivered by the release date or the backlog is still evolving (an euphemism for more scope being added)
• External dependencies keep getting discovered or the teams are not cross functional
• The team lacks expertise and past experience in making all integrations work together

Single-release projects also need to answer questions like these:

1. Do we fix all bugs that we find before we release? Do we really need to?
2. Unless you have automated continuous testing, is there any value in automating test cases since there may not be a case for regression!

What is your experience?

Have single-release projects always worked for you or only under specific conditions?

Image credit: https://unsplash.com/photos/TLBplYQvqn0

Posted under: Agile Maturity