Flow-based ways of working

The outer loop - how work is planned, prioritized, and flowed as a team - is the directive choice in ADR-0025, operationalized in ways-of-working.

The choice: flow, plus betting for the big rocks

The day-to-day method is WIP-limited continuous flow (Kanban-style: visualize the workflow, limit WIP, manage flow, make policies explicit, run feedback loops, improve collaboratively) - pull-based, no fixed sprints. Larger bets are shaped and bet Shape-Up style: an appetite (the time an idea is worth) replaces the estimate, inside the quarterly OKR frame. The request-lifecycle Request - the same seven-stage Request from the previous module - is the work item that flows; this decision does not re-sequence those stages, it defines how items are prioritized, WIP-limited, and pulled through them. Cogitave does not run vanilla Scrum.

Why not Scrum

Four Day-0 facts decide it. Small team plus agents as team members - Scrum's ceremonies exist to manage a coordination problem this team does not have. Trunk-based continuous delivery already ships continuously behind flags; a sprint boundary would batch work that is otherwise done. Velocity is a poison metric - trivially gamed, meaningless as a capacity number once agents are team members - so flow metrics (cycle time, throughput, WIP, aging) replace it, and never as a stack-rank. Cert-grade evidence must be a by-product, not a separate ceremony - PR review, a signed merge, and a blameless post-mortem already are the evidence an auditor reads.

The WIP limit protects human attention, not agent throughput

WIP limits apply to the human-attention budget - items awaiting review, sign-off, or the exception gate - not to raw agent throughput, so the one scarce resource (human review) never becomes a silently-growing queue. Agents pull, execute, and finish inside their least-privilege grant at the highest autonomy level the rails permit, emitting WORM evidence as they go; the human gate stays an exception handler, not a routine checkpoint on every item - the same doctrine AGENTS.md states in rules 6 and 7.

Feedback loops, and the deviation rule

The method carries its own loops: code review per Request, a design/architecture review at the lifecycle's document stage, a demo on bet completion, a retrospective at the cool-down beat, and a blameless post-mortem per incident - each closes into a tracked, owned action, never left as an un-actioned signal. Flow is the default; a squad may adopt sprints only under a written, specific reason - a fixed external delivery date, or a new team that cannot yet self-organize flow - re-evaluated each quarter. Absent a written reason, the answer is flow.