Delete Waste

Delete waste deliberately. Every agent, command, hook, and constraint in Gemba Flow exists to close one of the seven wastes from Toyota’s lean manufacturing system, translated for software delivery.

The seven wastes

The best example of deleting waste

When gembaflow v1.6.0 shipped the beads tracker, the team deleted approximately 420 lines of board-hygiene protocol from the agent instructions — in a single cutover. Those lines described how to move tickets through a GitHub Projects kanban board: how to query the board’s GraphQL API, how to claim an item with the correct field value, how to transition columns at each lifecycle event, how to guard against stale reads, and so on. Hundreds of lines of brittle, hard-to-test, often wrong protocol instructions.

None of it was ported. It was deleted.

The deletion was safe because the tracker now computes what the protocol was manually enforcing: bd ready returns the open, unblocked beads with no column-move required; bd update <id> --claim is atomic across all workers with no race; the board projections regenerate deterministically from the beads state without any agent intervention. The protocol existed to paper over what the old tooling could not do automatically. When the tooling did it automatically, the protocol became waste — instructions that added cognitive load without adding value.

This is the canonical example of deleting waste in Gemba Flow: not “write less” or “simplify,” but “identify what the system now does automatically and remove the human protocol that duplicated it.”

The same principle applies at every scale. When CI catches a class of defect, delete the manual checklist item. When the pre-push hook enforces a lint rule, delete the code-review comment reminding people to run lint. When Memory MCP persists a pattern, delete the inline comment explaining it. Deletion is always the goal; the countermeasures are the path to making deletion safe.

1. Inventory → Partially done work

Unfinished code, features, or documentation sitting idle. An unsupervised agent can churn out half-finished PRs faster than humans can review them. Without constraints, you accumulate inventory at machine speed.

Countermeasures: Computed Ready (bd ready = open + unblocked) caps the in-flight queue automatically; one bead at a time; worker → reviewer → human pipeline; short-lived feature branches that force completion.

2. Overproduction → Extra features

Building functionality nobody asked for. Agents are eager to please: ask one for a login page and you get OAuth, magic links, biometrics, and a password strength meter. Overproduction is the default mode for generative AI.

Countermeasures: Product Manager gates what gets built; Product Owner gates what is ready to build; /lock-scope formalizes the MVP boundary; acceptance criteria in tickets keep the agent honest.

3. Extra processing → Relearning

Every agent session starts with an empty context window. Without institutional memory, the agent re-reads the same files, re-discovers the same patterns, and makes the same mistakes — every single time. Relearning waste becomes catastrophic at agent speed.

Countermeasures: Memory MCP entities (CompletedTicket, PatternDiscovered, LessonLearned) persist across sessions; the 4 Power Sections in tickets front-load context; /log-session captures what each session learned.

4. Transportation → Handoffs

Agent-to-agent handoffs are fragile. Context windows do not transfer. If the worker’s implementation intent is not captured in the PR description, the reviewer agent reviews blind.

Countermeasures: Structured PR template; GO/NO-GO review format; ticket format with 4 Power Sections; ensure-github-account.sh hook for identity switching at handoff boundaries.

5. Waiting → Delays

Agents work fast but block on human decisions. A PR sitting unreviewed for two days has wasted the agent’s speed advantage entirely. The bottleneck shifts from code production to human review bandwidth.

Countermeasures: bd ready keeps the queue stocked without manual column moves; CI auto-fix protocol (up to 3 retries); reviewer agent starts review immediately; the human’s role is scoped to the final merge decision — highest-value, lowest-frequency.

6. Motion → Task switching

Frequent context switching reduces focus. An agent that juggles three tickets will do all three poorly. Context windows are finite — switching tasks means losing context, which means relearning.

Countermeasures: One ticket at a time; agent role specialization (each agent does one type of work); /work-ticket does exactly one thing; explicit “no parallel work” rule.

7. Defects → Defects

Agents produce plausible-looking code that may be subtly wrong. They do not feel uncertainty — they generate with equal confidence whether the code is correct or hallucinated. Defect generation can outpace defect detection unless the system is designed to prevent it.

Countermeasures: Quality engineer agent writes BDD plans up front; PR reviewer red flags; pre-push hooks; CI gates; “never merge with failing tests” as a hard rule; error receiver auto-files production bugs as tickets.

Vibe coding optimizes for code generation throughput. Lean says throughput of code is irrelevant; what matters is throughput of value to the customer.

Where to go next

• If you want the agent roster that enforces the waste reductions: Structured Handoffs.
• If you want the practices that implement them day-to-day: Hygiene covers the four user-facing practices.
• If you want to see the controls that catch what the practices miss: Layered Controls.