Skip to content

Agile for Small Teams

Everything so far assumed a team. But agile's best ideas survive contact with a team of one — or three — if you keep the parts that earn their keep and drop the ceremony.

The solo developer's agile

You are the Product Owner, the Scrum Master, and the team. What survives:

  • A backlog. One ordered list of "what's next." The discipline isn't the tool — it's that there's one list and the top is always the next thing. A text file works.
  • Small batches. Finish something shippable regularly. The build-learn loop doesn't need a sprint boundary; it needs you to stop polishing and show the thing to someone.
  • A personal retro. Every week or two, ten minutes: what slowed me down? What will I change? Write it down — memory lies about process the way it lies about everything.
  • WIP limit of one (or two). Finish before starting. The solo developer's biggest enemy is eleven half-finished branches.

What to drop: standups (talk to the dog instead), story points (you know how fast you are), planning poker (you'll agree with yourself suspiciously often).

The 2–5 person team

Keep it lighter than Scrum-by-the-book:

  • A board (Kanban-style, even if you sprint). Columns match your actual workflow; WIP limits stay.
  • A weekly planning moment. Not a two-hour ceremony — thirty minutes deciding what's next and who's doing what.
  • A demo habit. Show working software regularly, even if the "stakeholder" is each other. Demos kill "almost done" as a permanent state.
  • A retro that changes things. Small teams can act on retro items immediately — that's the advantage; use it.
  • One prioritizer. Even of three people, one person breaks ties on what matters most. "We decide together" works until it doesn't, usually at the worst moment.

What "done" means (write it down)

Small teams skip this and pay for it forever. A shared, written definition of done — tested, reviewed, documented, deployed, whatever your bar is — ends more arguments than any framework. Tape it to the wall (or the top of the backlog file).

The one practice that matters most

If you keep exactly one agile practice, keep the retrospective — the regular, honest look at how the work is going and one change to try. Iterating on the product is agile; iterating on how you work is what makes it compound. Teams that never examine their process get the same problems forever, just faster.