Continuous Flow

Kanban, not Scrum. A priority queue, not fixed sprints. Continuous delivery, not batch releases.

Work doesn't fit neatly into week-long boxes. Some tasks take three days. Some take ten. Forcing them into artificial time boundaries adds ceremony without adding value.

No Ceremonies

There's no velocity tracking, no planning poker, no burndown charts. Just a priority queue. Pull the next task, execute it, deploy it, repeat.

The Priority Queue

The client maintains a ranked list. The top item is the highest priority. The developer works top-down: finish what's in front, then pull the next thing.

Priorities shift? The client reorders the list. No sprint replanning, no ceremony. The developer is always working on what matters most right now.

This requires discipline on both sides. The client has to actually prioritize — not mark everything urgent. When it works, it cuts through ambiguity fast. No scope debates, no negotiation. Just a clear stack and continuous execution.

Six-Week Cycles for Bigger Bets

For significant features, think in six-week cycles — long enough to deliver something end-to-end valuable. A core capability implemented, integrated, tested in production, and iterated on based on real feedback.

A cycle isn't a deadline. It's a planning horizon. "In six weeks, we expect X to be working." Comes in at five weeks? Great. Slips to seven? Fine. The cycle serves orientation, not ceremony.

Why This Works

Software development isn't predictable enough for two-week sprints. Requirements clarify during development. Priorities shift based on what users actually do. Technical surprises surface at the worst times.

Continuous flow embraces this reality. The developer is always working on the most important thing, even as that definition changes. There's no overhead from sprint planning, no theater around velocity, no rituals that exist to feel productive rather than be productive.

Build it. Deploy it. Get feedback. Pull the next priority.