Minimal Viable Product

For software projects in the Agile/Lean side of the IT industry, we are often chasing “Minimal Viable Product” (MVP). Moving clients from a series of 18-month delivery slogs (“Waterfall” was very popular in the 90’s) to iterative, is easier when you can get them to believe that you’ll be able to go live in weekly intervals after that first push.

Obviously, sequencing the highest business-value stories for that MVP is appropriate. Consequentially, delaying some functional stories until after that initial go-live is key. At least, the ‘some’ that you’ve analyzed as non-critical to the initial MVP release. Back in the 90’s customers used to negotiate hard for all the items on the “User Requirement Checklist”, because it was going to be 18 months to the next release (or phase), but that’s not the case with Agile. Functionality flows into an application during a modern project, and you can measure it. From that trust and confidence emerge.

But what of Non-functional stories?

The answer is to generally delay them as long as the cost of implementation is flat. If the cost of the delayed non-functional story is beginning to hockey-stick, or you’ve left no reasonable contingency, then you’ve left it too late.

It could be that you know exactly what you’re going to do, and it’s a pure implementation cost. If this is the case, then it’s all about trading the cost of that story with a more valuable functional one.

Delayed Decisions?

It could be that it’s a decision that you’re delaying. Imagine you’re using MongoDB in an early version of the new app, but it’s clear for long term needs you’ll need a full relational schema for reporting. You might be torn between the Java ORM tools: Hibernate and MyBatis (or NHibernate and Dapper for .Net). The cost of indecision could be growing very gradually - more “entities” even if it is cheap to code I/O to MongoDB for new entities. That could be close enough to flat for you to say that the delay is worth it, as you’re able to focus on functional deliverables for longer.

Delaying to after the initial go-live?

You could also say that the cost of delay is still flat(ish) for the non-functional decision after you’ve gone live with the initial release. In this case you need a data conversion to populate the relational schema from accumulated Mongo records. You might also count that as as a relatively constant cost, rather than something ballooning.

Delaying indefinitely?

This is now getting interesting - you may choose to not-decide even longer. Mongo could be working for you, and you might choose to do a longer series of releases with it, or indeed now plan to never change to relational at all (savings).

Changing your mind during the delay?

It gets even more interesting if you consider that you could make a post-go-live decision to go to Apache’s Cassandra instead which is far closer to Mongo than Relational + ORM is. If you’ve made that decision, you saved the cost of going to one of Hibernate or MyBatis inappropriately, and essentially back. Your initial decision to not implement is now a hedge-bet that has paid off.

Risks

The risk is that you might not be able to predict when that hockey stick change in costs will be. The challenge is coolly predicting when that hockey-stick happens, and being able to bank the preferred functional changes in the meantime. Added to that is a need to convince your risk-averse customers to relax, and be pleased about the modestly smarter investing.

Many times I’ve witnessed a project that prioritized third-normal-form DB design before interactivity and user experience were coded. Back in the 90’s that was ordinary. More recently in the client/server era, with Agile/Lean as a methodology it has been unusual, and could be one factor that tips projects towards failure. I enumerated others previously.

Of course, this really isn’t new thought. It’s yet one more technique pulled from the world of lean manufacturing into software project management, and is routinely used by experienced PMs and Techies.

Prior Art

[2006] Jeff Atwood blogged - The Last Responsible Moment - on Mary and Tom Poppendieck’s Lean Software Development: An Agile Toolkit. Jeff’s piece is punchy and well written, and the Poppendieck’s book is exhaustive and authoritative.