How Agile can destroy your Start-up

No, you haven’t clicked the wrong link – I did just say that. As an Agile advocate I don’t normally suggest erring on the side of caution when it comes to Agile, but there is an exception and I wanted to address it because over the years it’s something I have seen with quite a few start-ups. It’s not Agile that is the problem, but the way in which people use it.

The History

Before Agile came along, many businesses used the Waterfall methodology: the spec is written, and the business sets out to deliver everything in that spec. One big project is delivered, for a cost.

According to Agile thinking, the problem with a Waterfall approach is that the initial set of requirements includes a whole host of things you don’t need, and as you begin to use the system, you realise that there’s a whole host of things that you do need, that weren’t included in the initial spec.

The Agile approach incorporates changes as you go along – start by building the essential parts of the system and then change it around as and when you need to. There’s a strong focus on the product and customer satisfaction, whereas Waterfall is concerned with just meeting the initial spec.

How people use Agile in the wrong way

The flexibility that Agile provides enables people to change their minds and keep adding new requirements to a project. These additional requirements certainly deliver more business value, but the challenge is knowing when to stop.

In many cases with start-ups, they often keep adding extra bells and whistles. Additional requirements get prioritised and added into the system either at the expense of other requirements, or by increasing the time needed to develop the initial iteration. This results in a bloated product – a product that’s got too much going on and more features than are needed.

So, why does that matter?

In a start-up life cycle, it’s the period of time before having any customers that carries the most risk. Pre-launch, it’s unclear whether customers will like the product – they might be unwilling to buy or use it, or another company might beat you to it, launching a similar product before yours is ready. Getting a good enough product out is critical.

Getting investment before having any customers is difficult and expensive; a significant amount of equity must be exchanged in return for seed investment. A start-up needs 20-25% investment at the seed phase to be able to get to the proof-of-concept phase, at which point they’ll likely be looking at further investment to get to the point where they can actually launch.

Therefore, if a start-up keeps adding on, enjoying the flexibility of an Agile approach and putting new ideas into the project – all the while not having any customers, they stay in that high-risk phase, and it’s extremely costly.

Example: A full system might require 10,000 days’ worth of work to get to the point at which it’s a viable, solid system. By year two, after the launch, those 10,000 days will have cost the start-up, let’s say £5m. To deliver all of that pre-launch, the start-up would need to have raised £5m of investment upfront and given away a significant amount of equity.  

If that start-up was instead able to get to the point where it could launch a product with just 1000 days work, it would only need a tenth of the development investment pre-launch, and the Founders would retain a higher percentage of equity. 

Every additional feature that isn’t required in those early days, costs the start-up. Each new feature costs the start-up equity and delays the launch, but because the product hasn’t been launched, investors want more equity – it’s a vicious circle.

Agile will allow you to keep adding requirements whenever, but the question is, when do you actually stop and get the product and business launched?

The Solution

There are two Agile principles that can be used with a Lean approach to create a minimal offering – that is, the very least that can be done to get something out there and test the water with customers.

Minimum Viable Product (MVP) – building just enough to be able to demonstrate part of a system.

Minimum Marketable Product (MMP) – the minimum that can be done to release something to the public as a working product.

A Product Owner evaluates all the requirements and the estimated business value, before only choosing the requirements that need to be done.

In the example above, the start-up getting to the point of launching a product with just 1000 days work is MVP and MMP playing out; the Product Owner has identified the smallest number of features that allow the product to achieve its basic functional effect, launch, and start getting much needed feedback from customers.

Getting the balance right

I’m not for a minute suggesting that it’s a good idea to rush through development of software and systems to just launch something. Of course, you must develop a system that works and is likely to be well received by customers, but you also need to know when to stop.

Start-ups should always be thinking about what is absolutely necessary pre-launch, considering feature cost against the feature benefits in relation to the business strategy, because adding in a feature after launch is so much cheaper.

A Product Owner will assess from stakeholders the value of adding in another feature, however, it’s a difficult job and often those they consult – friends or a small user group – aren’t typical users.

As soon as you can actually start releasing a piece of software and it’s available, you have REAL customers. Those customers can validate whether or not features are valuable and which areas of a system need enhancing.

It’s likely that out of the three or four different areas of a system, customers will only give feedback on one or two of them and completely ignore the others. The areas the customer is concentrating on become the start-up’s areas of focus. If you don’t get to the point of launch (because you’re adding on and adding on lots of different features), you won’t know which features will be important to the customer.

Releasing earlier with fewer features will give you a clear understanding of what people want and will value long term, closing the feedback loop between perceived value pre-launch and real value post launch. This creates a solid business that’s financially stable and will give you the flexibility to keep reacting to customer feedback.

Written by Toby Parkins
Director of Headforwards