Avoid Scrum if you are a startup

Introduction

A fundamental choice in software development is how to manage the development process. Nowadays this will likely involve some form of agile framework or methodology, such as XP or Scrum. I have mostly worked in companies that used Scrum. I have seen it work well for mature companies but it is not the right choice for a startup. In this post I explain why.

The lean startup

When I refer to a 'startup' I mean a company that fits the definition given by Eric Ries:

The uncertainty is how to build a sustainable business around the vision of the founders. In order to reduce that uncertainty Ries advocates an approach of validated learning. Each learning is the outcome of an interation of the 'build, measure, learn' feedback loop. The product team would proceed like so for one such loop:

1. The team identify what they need to learn.
2. They decide on the product or feature they should build to gain that learning.
3. They build it.
4. They measure -- quantitatively or qualitatively -- how that change affects their users.
5. They use those measurements to determine what they have learnt.

This learning can now be added to all the previous learnings. In this way the current state of the product or service (and ultimately the business) is an accumulation of all the validated learnings to date.

The problem with Scrum

When you adopt a particular methodology to manage the software development process, you are optimising that process in some particular way. The problem is that it may not be appropriate for you right now. In the case of Scrum, I would argue that it optimises keeping your developers busy. There is a product backlog that represents planned work for the development teams. It has been refined and story-pointed. At the start of each sprint, a sprint backlog is created that represents a realistic amount of work for the team. If the developers complete their work early, additional work items can be included in the sprint. These might have previously been identified as stretch goals for the sprint. The velocity of the team is tracked to inform future sprint planning.

This can be successful in established companies. I worked for a jobs Web site that employed around 50 developers. The company was mature and successful. There was a deep product backlog for the development teams. The development work was about fine-tuning the site and evolving it rather than any kind of revolutionary change.

This is very different to a startup. The company is not yet sustainable, and it relies on funding to survive. If those funds run out, the company fails. There is extreme uncertainty about the product or service and the business model, such that the current strategy might be correct or it might be fatally flawed. If you optimise the development process to reduce the time taken by the 'build, measure, learn' feedback loop -- while not compromising the long-term quality of the product or service -- you give yourself the best chance of success. The more loops you perform within your available runway, the more experiments you can run and the more times you can pivot. Scrum does not help you with this. Instead it encourages a pipeline of planned work that might be the implementation of a flawed strategy.

Conclusion

I think it is natural, if you have had good experiences using Scrum in mature companies, to also use it in a startup. But this is a mistake. The development process should be optimised for the aspect that contributes most to the success of the company, and for a startup it is the 'build, measure, learn' feedback loop. Scrum does not optimise for this and so it is not a good fit for a startup.

Changelog

• 2022-06-06 Initial version