Agile for a Team of One: Freelancers, Founders and Side Projects

Most agile writing assumes a team. Scrum, for example, defines a Scrum Team of a Product Owner, a Scrum Master and Developers. So what about the freelancer juggling three clients, the founder building a product alone, or the person squeezing a side project into evenings?

You cannot run Scrum by yourself in the strict sense, and that is fine. Many of the most useful agile ideas work at any size: make your work visible, limit how much you start, work in short cycles, get feedback early, and reflect regularly.

This guide shows how to adapt those ideas for a team of one without drowning in process.

What carries over, and what does not

The Scrum Guide (November 2020) states: "While implementing only parts of Scrum is possible, the result is not Scrum." Working solo, you will be borrowing parts, so think of this as agile-inspired personal practice rather than Scrum.

What carries over well:

• A single, ordered list of what matters most.
• A visible board with limits on work in progress.
• Short, fixed planning cycles with one clear goal each.
• Frequent feedback from the people you serve.
• A regular look back at how you are working.

What does not carry over: events designed for group coordination, like a daily meeting, and the separation of roles. You hold every role, which brings its own risk: no one else will challenge your priorities.

Step 1: Set up a personal Kanban board

Personal Kanban, an approach to applying Kanban to individual work, rests on two rules: "Visualize your work" and "Limit your work-in-progress."

A simple solo board has four columns: Next, Doing, Waiting and Done. Next holds a short list of items you have chosen to do soon. Doing holds what you are actively working on. Waiting holds items blocked on someone else, such as a client's approval. Done shows what you finished.

Set a low limit on Doing. A practical starting point for many people is two or three items. The Kanban Guide (May 2025) explains the reason for limits: you "should start work on an item (pull or select) only when there is a clear signal that there is capacity to do so." When Doing is full, finish something before starting something new.

Keep Waiting visible too. Items that sit there are easy to forget, and the guide warns against letting work "age unnecessarily."

Step 2: Keep one ordered backlog

Write every idea, request and task in one list, then put it in order. The Scrum Guide describes a product backlog as "an emergent, ordered list," and the word ordered matters most when you are alone, because everything will feel urgent.

For freelancers, the hard part is balancing clients. One option is to tag each card by client, or use a horizontal lane per client on your board, while still keeping a single limit on total work in progress. For example, imagine a freelance designer with three clients: separate lanes make it obvious when one client's work has stalled, and the shared limit stops her from starting a fourth project on top.

Step 3: Plan in short cycles with one goal

Borrow the idea of a sprint. Pick a cycle that fits your life, often one week, and start it with a short planning session. Choose one goal for the cycle, similar to the Scrum Guide's Sprint Goal, and pull in only the work you can realistically finish.

For example, imagine a side project you work on for about five hours a week. A good weekly goal might be "publish the signup page," not "build the app." Small goals finish; vague ones drift.

Step 4: Get feedback from real people early

The Agile Manifesto's first principle puts "early and continuous delivery" of value at the top, and another principle favors delivering frequently, "with a preference to the shorter timescale."

Working alone, it is tempting to polish in private. Resist it. Freelancers can share rough drafts with clients early, before the work is expensive to change. Solo founders can put a simple version in front of potential customers. Side-project builders can show a friend or a small community. Each piece of feedback becomes a new item in your ordered list.

Step 5: Hold a weekly review and retrospective

At the end of each cycle, take 20 to 30 minutes. First review the result: what did you finish, and what did you learn from the people who saw it? Then reflect on how you worked. The Manifesto's final principle says to reflect "At regular intervals" on how to become more effective, then adjust.

Useful solo questions include: what took longer than expected, and why? What did I start that I should not have? What one change will I try next week? Write the change down and put it on your board so it actually happens.

Step 6: Measure lightly and keep it sustainable

You do not need a dashboard. Record the date each card enters Doing and the date it reaches Done. The Kanban Guide defines cycle time as "The elapsed time between when a work item started and when a work item finished," and throughput as "The number of work items finished per unit of time."

After a month or two, those two dates per card tell you how long typical work really takes. That helps you quote timelines to clients and set realistic goals, based on your own history rather than hope.

The Manifesto calls simplicity, "the art of maximizing the amount of work not done," essential, and it favors a pace you can "maintain indefinitely." If your system takes more time to maintain than it saves, cut it back. A paper board and a weekly half hour can be enough. Our guide to setting up your first Kanban board covers columns and limits in more depth.

Key takeaways

• Solo work cannot be Scrum, but agile ideas scale down well.
• Use a personal board with a low limit on work in progress and a visible Waiting column.
• Keep one ordered list, using tags or lanes to balance multiple clients.
• Work in short cycles with one goal, and seek feedback early.
• Review and adjust weekly, and track start and finish dates to forecast honestly.

Sources

• Personal Kanban, Personal Kanban 101
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• Agile Manifesto authors, Principles behind the Agile Manifesto (2001)