For a startup, building agile software means two things. The first is working in short cycles that each end with something a real user can try, so that what you learn changes what you build next. The second is keeping the software itself cheap to change, because a startup’s first idea of its product is rarely its last. This guide covers both, and leaves out the parts of agile practice that a team of three or four does not need.
What agile means for a startup, and what it does not
Agile comes from a short statement of values published in 2001, which prefers “responding to change over following a plan” and “working software over comprehensive documentation”. A startup is the textbook case for it. You do not yet know which features customers will pay for, so a method that commits the whole budget to a specification written on day one is a poor fit.
It is often misread. Agile does not mean no plan: it means a plan that is revised every couple of weeks in the light of evidence. It does not mean no documentation, no budget or no deadline. And it is not a set of meetings. A team can hold every meeting in the book and still spend six months building something nobody has tried.
The smallest process that works
Scrum is the best known agile framework, and its rulebook, the Scrum Guide (2020), is deliberately short. A small startup team can take the core of it without the overhead.
One ordered list, owned by one person. Everything the product might do goes into a single list, the Product Backlog, with the most valuable item at the top. One person decides the order. In Scrum this is the Product Owner, and in a startup it is nearly always a founder. If two founders both set priorities, the developers end up choosing between them.
A short, fixed cycle. Scrum calls this a Sprint and allows up to one month. One or two weeks suits a startup better, because each cycle is a chance to change direction.
A goal for each cycle. One sentence stating what will be true at the end, such as “a customer can sign up and pay without our help”. A goal survives the surprises that a list of tasks does not.
A daily check-in. Scrum’s Daily Scrum is limited to 15 minutes and is for the people doing the building. Its purpose is to spot what is blocked, not to report to management.
A demonstration of working software. At the end of every cycle, show what was built to someone outside the team: a customer, a pilot user, an adviser. Slides do not count. This is the Sprint Review, and it is the event that makes the others worth holding.
A look back. A short conversation about what to change in how the team works, with one improvement carried into the next cycle.
Scrum also has a Scrum Master, who is accountable for the team’s effectiveness. That is an accountability, not necessarily a full-time job, and in a team of four it is usually covered by the most experienced person. A certificate such as Certified ScrumMaster, which involves a 16-hour course and an exam, shows that someone has studied the framework. It does not show that they have run a team.
If work arrives as an unpredictable stream, as it does once you have live customers reporting problems, a flow-based method may suit you better than Sprints. We describe it in reasons to use Kanban.
The table below separates what a small team needs from its first week from what can wait. The technical items in it are explained further down.
| Keep from the first week | Can wait until you are larger |
|---|---|
| One ordered backlog and one person who owns it | Story points, velocity charts and estimation sessions |
| Cycles of one or two weeks, each with a goal | A dedicated Scrum Master or agile coach |
| A demonstration of working software every cycle | Frameworks for coordinating several teams |
| Source code in version control | Roadmaps detailed beyond the next quarter |
| Automated tests on the paths that take money or hold customer data | Splitting the system into many separate services |
| A release process that is automated and repeatable | Elaborate reporting dashboards |
Build the first release as an experiment
The first version of a startup’s product exists to answer a question: will people use this, and will they pay? Build the least that can answer it properly. Our article on the minimal viable product approach covers how to decide what goes in and the ways the approach goes wrong.
Two habits make the experiment useful. Decide before launch what you will measure and what result would make you change course. Then put the product in front of real users while it is still embarrassing in places, because feedback on a rough product that exists is worth more than opinions about a polished one that does not.
Keep the software itself easy to change
Process is half of it. The other half is technical, and a non-technical founder should still ask about each of these.
Version control from the first day. Every change to the code is recorded and can be reversed.
An automated path to release. When a change is saved, it should be built, tested and made ready to release without manual steps. This is the heart of DevOps, and it is what allows a small team to release several times a week without fear.
A simple structure. One well-organised application is easier to change than a dozen small services, and a startup does not have the problems that many services solve.
Mainstream technology. Choose languages and frameworks that many developers know. An unusual choice becomes a hiring problem as soon as the person who made it leaves.
Shortcuts taken on purpose. A startup should take shortcuts to learn faster. Write each one down, with what it would take to put right. Shortcuts nobody recorded are how technical debt becomes a crisis at the point the product starts to grow.
Everything in the company’s name. The source code repository, the cloud hosting account, the domain name and the app store accounts should belong to the company, not to a founder’s personal email or a contractor. Investors will check this, and so will any buyer. The contracts with employees and contractors should say who owns the work, and that is a matter to take legal advice on. Our answer on who owns the source code sets out what to look for.
Working with an outside team
Many startups have no developers of their own at first and use a software company or freelancers. Agile working still applies, with a few things settled at the start.
You remain the Product Owner. A supplier can advise on priorities but cannot know your customers better than you do, and a founder who is too busy to attend the demonstrations will get the supplier’s best guess.
Agree how the work is paid for. A first release with a clear scope and agreed acceptance checks can be bought at a fixed price, which protects a limited budget. Continuing development after launch, where priorities change monthly, is better arranged as a regular monthly amount of work.
Ask to see working software every cycle, on a test site you can log in to yourself, and ask for access to the backlog and the code from the first day.
A check to make this month
Ask whoever builds your product three questions:
- When did someone outside the team last use the newest version, and what changed as a result?
- If we needed to release a one-line correction today, how long would it take and how many manual steps are involved?
- Which accounts holding our code, hosting and data are not in the company’s name?
A team working in an agile way can answer the first with a date, the second in minutes and the third with “none”.