Is your Minimum Viable Product actually viable?

Let’s examine one of the most-shared images relating to agile software development from last year. There are a few variants of the idea (and I apologise for not knowing who to cite as the original source), but the basic theme is the same. Instead of developing a car in progressive phases, they show the delivery of simple, usable evolutions of vehicles until the product vision is reached. I’m not sure this is actually a great example of what a minimum viable product is – or what we are trying to achieve.

What is an MVP?

Very simply, a minimum viable product is the very essence of what you are trying to achieve, leaving any non-essential functionality or other features to be added later.

If your product vision is to create a new e-commerce site, your MVP would perhaps include enough to display a list of products, allow users to add them to a basket and then checkout (handling delivery and payment). That’s about it.

Going back to the featured headline image, if your product vision is to create a sports car or a family saloon (sedan), my expectation of an MVP would be a very basic car. It would be drivable, and include the key basic functions you’d expect any car to have (a chassis / body shell, wheels, brakes, steering, seats and a source of propulsion). It’s not going to be a skateboard or a bicycle…

An MVP will not deliver everything you want, its scope is just the bare-bones of your product. Additionally, it will probably not be something you could use commercially (that would be a Minimal Marketable Product – which I’ll cover in another post) or necessarily include everything that you know you’ll need.

Why create a Minimum Viable Product?

There are two important reasons (for me) why I always aim to create an MVP before trying to add all of the “desirements” to the scope of our work:

Prioritisation

Creating an MVP forces you to prioritise, with the benefit (hopefully) of reducing the chance of a Boolean outcome – not delivering a working product by the end – and instead creating an outcome spectrum.

It takes an amount of maturity and a good understanding of the product vision, as it’s very easy to create a long list of “must-haves”, but if you don’t learn to chop away at some of the nonessential functions, you may not be focusing on the areas that enable the basic purpose of you product. We don’t have an unlimited amount of time, so what we do needs to occur in an order that reflects any technical dependencies, as well as business priority. A great satellite navigation system isn’t much use on a car that can’t drive anywhere.

A Learning Tool

Most importantly, an MVP should help you to understand some of the key decisions you’ll need to make – and expose any fundamental challenges in what you’re trying to achieve.

There is no value in creating something that doesn’t meet your product vision, unless it answers some of the questions you’re going to face getting there. Does producing a motorcycle provide any experience that will influence your cars design? Not many of the more important aspects, I’d imagine…

Now, I don’t develop cars as a profession, but I’d guess that some of the elements you’d need to consider early on would be the passenger compartment (how many occupants it needs to carry), how it’ll be propelled (combustion engine or electric motor) and how the chassis and wheel layout interact with the design. When you discover that the size of the battery required to power the vehicle means that something will have to be moved or changed to make enough space for it, you’ve learning something. Something useful.

Thinking back to our e-commerce site, we’d need a way to access our product data and display it. How will our web application connect to this repository? Where do we store our images – are they suitable for the web – do we require different sizes etc? Payment integration may provide its own set of challenges. If your e-commerce site can’t take payments, how important is a search auto-complete feature?

Your team’s velocity is another thing you’ll start to understand. Building the basic elements of a more complex product will help you to assess the overall effort required to reach the product vision – but what you do has to be relevant.

Some elements of your MVP may even be throwaway. You might find that something you’ve developed has a significant shortcoming – enough to merit a return to the drawing board. The lessons learned bring you a step closer to the right solution. Learning about a bicycle derailleur isn’t a useful lesson towards producing a car.

If your product is a car, your MVP is a car. Not a skateboard, scooter, bicycle or motorcycle.

Managing technical debt

One common question I hear from teams new to Agile is “How do you manage technical debt?”. Agile is often blamed for producing more technical debt than more traditional approaches – whether or not that’s true, everyone should have a mechanism for tackling it.

What is technical debt?

For anyone unfamiliar with the term, very basically, technical debt is any underlying element of your software that you should rework at some point in the future. Usually as a result of a previous decision or (in)activity that will impact the long-term value of your product, if left unaddressed.

It differs from a change initiated by the business in that it will usually be something either imperceptible to anyone non-technical and / or not involved in the technical implementation of the product (or certainly not obvious).

Ward Cunningham, credited with coining the term, describes this concept in the following way:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

He refers to object-oriented programming, but you’ll appreciate the concept applies universally, regardless of paradigm.

Unplanned technical debt

Unplanned technical debt is usually the consequence of external change, time pressures or a lack of understanding.

For example, maybe you produced a service that made heavy use of a rate-limited external API, on the assumption that your expected traffic volumes would never approach close to that value. Then, your product is a runaway success and you end up with more traffic than the rate limit allows, degrading performance.

Another example could be that your project made use of a UI library to produce your website, but now there are newer browser versions that the library does not handle, breaking layout and functionality in modern browsers.

You may have written an inefficient search algorithm, as you had to produce something very quickly at the time – but with further optimisation you could save significant server resources, needed for other processes going forwards.

From personal experience, I’ve had situations where I’ve discovered a much more elegant solution to a problem after the fact (where refactoring would improve pace of change and customer experience), towards the end of a project.

Planned technical debt

Sometimes you just have to accept that being able to produce something fast is occasionally better than (pro-actively) spending additional time on quality. For example, it’s quite valid to attempt to prove a concept in the quickest way possible, usually to answer an unknown factor (“will this work?”), over longer-term concerns.

This could result in things like a conscious decision not to include logging or perhaps you chose to skip adding any build automation, knowing that they would both be useful longer term. The key points with this approach is that the team has agreed the priorities, potential impact and any mitigation up front – the consequences of the situation are understood. As long as you address the issue later (or make a conscious decision to live with the issue), based on the business value balance, that’s fine.

When planned technical debt becomes particularly unhealthy, is when it emerges from a pressured, one-sided source – instead of as a natural result of collaborative effort. In Agile teams, this is usually the result of a dictatorial (bad) Product Owner – or someone else able to pressure the team into focusing on non-technical priorities, over the team’s overall agreed priorities. You could argue this is actually unplanned debt – but that divorces the responsibility from the stakeholders, who ultimately need to acknowledge that they have chosen this path.

The danger here is that the potential consequences of this type of technical debt are not understood. That’s a risky place to be – unbounded problems have a tendency to spread quickly – akin to spending on a credit card with no limit (and no one ever checking the balance). If your technical debt exceeds the value of the product, you’ve failed.

Balancing value

Successful software projects eventually need to achieve a level of balance between business functionality and technical architecture.

Too much focus on either side is not good. Businesses tend to focus on tactile features over practicality, while development teams want to produce academically elegant solutions that no one may actually want (or simply spend more time on it than the business value justifies).

Regardless on the cause of the debt, the way you tackle technical debt is largely the same. The team needs to prioritise effort together.

If your backlog refinement meetings are genuinely collaborative then you’d ideally have discussed and agreed your prioritisation of work to include a balance of business and technical needs – minimising debt in the first place.

While that may be the ideal, striking that balance isn’t always very successful, for a variety of reasons. Additionally, unplanned technical debt is a constant unseen threat – and it can build up at any time, even with the best of intentions.

Newly discovered technical debt should be bubbled-up (flagged) so that it can be addressed by the team. This means adding a story to the backlog with a description of the problem and optionally including a proposal to resolve it. When your backlog refinement meeting (grooming) occurs, you should have a mechanism to trigger triage of new stories, prompting a discussion about the issue. From there, your technical debt becomes like any other story being groomed:

• Flesh out the requirement – is it a problem?
• Break down any large chunks into smaller, manageable activities.
• Agree the acceptance criteria for it to be considered resolved (done).
• Prioritise based on the value to the product / feature.
• Add the stories to the appropriate sprint backlog.
• Review your balance of priorities again at the next planning session.

That’s it – when you become aware of technical debt, flag it by creating a story to represent it, let the team decide when and how it needs to be tackled – then deliver on your commitment.

Agile with deadlines using time-boxing

In an excellent article from Mike Cohn, where he talks about budgeting when you can’t estimate, he touches on an important but often overlooked Agile practice, time-boxing:

Instead of asking a team, “How long will this take?” the business thinks, “How much time is this worth?” In effect, what this does is create a budget for the feature, rather than an estimate. Creating a budget for a feature is essentially applying the agile practice of timeboxing. The business says, “This feature is worth four iterations to us.” In a healthy, mature agile organization, the team should be given a chance to say if they think they can do a reasonable job in that amount of time. If the team does not think it can build something the business will value in the budgeted amount of time, a discussion should ensue. What if the budget were expanded by another sprint or two? Can portions of the feature be considered optional so that the mandatory features are delivered within the budget? Establishing a budget frames this type of discussion.

I’m sure there will be distant shouts of “it’s done when it’s done”, but I regard that as a negative attitude and somewhat unrealistic. Everything we produce (in a commercial context) is paid for by the business, so ultimately they should be in control of how much they spend. Whilst time-boxing doesn’t guarantee they’ll get (everything) that they want, it should ensure costs don’t spiral.

There are three critical aspects to successful time-boxing, collaboration, ante and negotiation (think CAN you time-box).

Collaboration

In order to have the best possible chance of realising the value the business hopes to achieve within the time-box, the whole team will need a clear understanding of what the ideal outcome would be. Focus should be on what is really needed and how to prioritise to get there.

Negotiation

If there is enough uncertainty or too many unknowns, it’s crucial that the requirement is negotiable. As the article mentions, can portions of the feature be considered optional? The aim should be to negotiate a modular / gradual outcome where at least the lower spectrum of value can be delivered within the constraints with relative confidence.

This is very much an application of the INVEST characteristics defined by Bill Wake:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

This principle is usually applied to user stories, which is what the portions of the feature provoking the time-box should be broken down into.

Ante

The ante is the size of the time-box, the monetary stake in the game. If the uncertainty is very high, the business has to accept the risk that the stake’s value may not be returned.

Occasionally, due to the size or complexity of a feature (or possibly external factors), it may become clear that the feature MVP cannot be delivered within the time box. If it’s likely to be significantly incomplete, this should become clear relatively early on. If you’re 2 Sprints into a 4 Sprint time-box and have only completed 10% of the effort for the minimum viable elements of the feature, there’s a strong chance the remaining 90% will not be completed in the remaining time.

With the above example in mind, you have three choices:

• Fold – you’ve reached a point within the time-box where it looks like you’re not going to get a return so you fold early, ending the time-box.
• Call – you hold your nerve until the end of the time-box. It’s still possible that you’ll get the output / value you want. As we all know, burn-down is non linear.
• Raise – at the end of the time-box, the team may have delivered most of the portions of the feature, but you may now feel it’s worth a small extension (based on the team’s velocity) to add more value.

In theory, you could also raise the ante if the team didn’t deliver the minimum viable feature negotiated at the start. I’d usually recommend against this as it’s difficult to assess progress if you don’t have “working” software to base your projections against. Your budget (in terms of money or time) was negotiated early on – spending more than the feature adds is precisely what this approach should avoid.