Navigate Ways of Working
Founding Team Flow
The 1–4 person operating model at a glance: board shape and WIP limits, definition of ready and done, what replaces each ceremony, the human/agent protocol, flow metrics, and graduation triggers.
Founding Team Flow
Teams of 1–4. Continuous flow instead of sprints, with the board as the dispatch layer for people and agents. Full detail in the Founding Team Operating Model.
Below five people the problem is not planning, forecasting or capacity. It is finishing.
Same responsibilities, same standards, same artefacts. A queue instead of a cadence.
The Board: one per product stream
Plus a Dropped list (category dropped)
Deliberately not doing, with the reason on the card. It is what lets the board answer “what are we not doing?”, and a list’s meaning comes from its category, never its name.
Definition of Ready: Backlog → Next
The test Could someone who was not in the conversation execute this? That is also exactly what makes a card dispatchable to an agent, which is why the standard is worth holding.
Definition of Done: two gates
completed and moved to Done.| Always reviewed | Self-certified, straight to Done |
|---|---|
| Auth, payments, personal data | Copy, content, configuration |
| Schema changes and migrations | Internal tooling and scripts |
| Shared or public interfaces | Contained fix with a test that reproduces the bug |
| Hard to reverse, or blast radius wider than the feature | Small feature work in an established pattern, criteria objective and checked |
| A new user-facing flow | Requires green CI, behind a flag or trivially revertible |
| Anyone new to the codebase, while coaching is worth the delay | Never agent-authored work: the human reading it is the second pair of eyes |
| Anything the author is unsure about | Never to clear a review backlog |
What keeps the exception honest The route is decided when the card is shaped, not when the author wants to ship · one line on the card says which route and why · an escape shrinks the class: self-certified work that reaches a customer broken puts that category back under review until it earns its way out.
At one person, the always-reviewed list is what you pay for A peer founder, an advisor on retainer, two contractor hours a week on the customer-facing paths. The self-certified class is what makes a solo founder viable; the always-reviewed list stops that being an excuse. An agent reviewing an agent is a useful filter, not a second pair of eyes.
WIP Limits: what replaces sprint commitment
| Value | Kind | |
|---|---|---|
| Everything you work on is claimed | absolute | The rule. A running session with no claimed card is invisible work, and every number below becomes fiction. |
| In your own hands | 1 | A fact about attention, not a policy. You cannot hold two implementations in one head. |
| Supervised alongside it | 1–2 | Where reading quality falls off for most people. Run three if the work allows, claim three, watch review latency. |
| In flight / person | 3, soft | In hand, supervised, blocked, awaiting review. A trigger for a comment, not a gate. |
| Doing + Review, team | 2 × people | Review is work in flight. Treating it as free builds a queue behind a team that feels busy. |
| Next | 2 × people | Longer than that is shaping done too early. It goes stale. |
Why no per-person number is hard A limit you can only obey by not recording what you are doing buys a tidy board at the cost of a true one. Two Claude Code sessions against two cards is two claimed cards: not a breach, just an accurate board. If the honest answer keeps breaking a number, the number was wrong → change it at the review, in writing.
So what polices it The sentence test (a comment saying why you hold what you hold) · the preference order: finish → unblock someone else → help finish → start · the weekly review, which puts unexplained parallel work back in Next · aging WIP and review latency, where over-parallelisation shows up as a number rather than an opinion.
Four reasons to hold a second card, all legitimate
The first is genuinely blocked and you cannot clear it · something urgent arrived and displaced it · an agent or a second session is working one of them · you are waiting on the machine. Urgent bugs never queue: take it, displace what you held with a one-line comment, tell the other owner afterwards rather than asking first.
Cadence: dropped, and what survives
| Sprint ceremony | Here |
|---|---|
| Sprint planning | Nothing. The order of Next is the plan. |
| Refinement | Async shaping on the card; contested items to the weekly review. |
| Standup / mid-sprint | The board, plus stale-card automations. |
| Demo | Ship it and post the link. Monthly 20-min walkthrough for outsiders. |
| Velocity / points | Gone. Cycle time and throughput instead. |
| Survives | When | Output |
|---|---|---|
| Queue review | 30 min / wk | Next re-ordered; blockers owned |
| Flow + retro | 45 min / mo | One written process change |
| Direction | ½ day / qtr | Where next quarter goes, what is dropped |
| 1:1s | fortnightly | Never less. First to vanish, last you can afford to lose. |
The Protocol: identical for people and agents
blocked / waiting, a comment naming exactly what is needed, stop.That last line is the governance model Everything an agent produces passes a human gate, and the gate is a list on the board rather than a good intention.
Agents Must Not
Automations to Set Up Day One
| Stale | 3 days untouched in Doing → comment + notify |
| Abandoned | 7 days → back to Next, with a comment saying why |
| Review waiting | Enters Review → notify the named accepter |
| Shipped | Completed → post to the team channel |
| Dispatch | Enters With Agent → webhook starts the run |
Flow Metrics: five, monthly
| Metric | Response when it goes bad |
|---|---|
| Cycle time median + spread | A long tail means cards too big or review too slow. Split, or fix the gate. |
| Throughput cards/week | Falling with WIP steady: cards are growing. Falling with WIP rising: too much started. |
| Aging WIP oldest in flight | The leading indicator. Older than 2× median cycle time → next queue review. |
| Blocked time | Persistently high on waiting is an external-dependency problem, not a productivity one. |
| Review latency | Rising means the gate is becoming theatre. Fix it before it gets skipped. |
Forecast with a range, not a date “Most cards like this finish in three to eight days” is true and useful. “We estimate four days” is neither. Anything beyond these five is decoration until it changes a decision.
Who Holds What
| Responsibility | Shows up as |
|---|---|
| What gets built next | The order of Next (Owner of What) |
| A card being ready | Definition of ready (What drafts, How confirms) |
| How it gets built | The implementation-plan comment (Owner of How) |
| It does what it should | Review → Done, by a named accepter |
| Production at 2am | A named rotation + the runbook in the wiki |
| Flow health | The monthly numbers (Owner of How) |
| Growth and wellbeing | The fortnightly 1:1, one named person |
| Escalation backstop | Someone outside the team, named in advance |
The two owners are not one person Even at two. Especially at one, in which case say which hat you are wearing. Triage is the What hat; pulling from Next is the How hat.
Anti-Patterns
Graduating: move on a trigger, not a budget
| Trigger | Move |
|---|---|
| 5th and 6th person join | Stay on flow; add a weekly commitment at the top of Next |
| 7th person, or a second product area with its own stakeholders | Adopt the sprint model properly, as one squad |
| Commitments need dates beyond your cycle-time spread | A planning cadence |
| More than ~6 people pulling from one board | Two boards → two squads → the full process |
| The queue review runs long every week | Refinement as its own session, ahead of the work |
| Review is consistently the bottleneck | A named quality owner, before any other hire |
The migration is small by design Keep the board, the lists, the definitions of ready and done, the WIP limits. Add a sprint boundary around the top of Next and a session to set it. That is the whole change, which is the point of running one operating model at both sizes.