Tools · General business
Continuous Improvement
Turn a recurring problem into a root cause, and a chaotic workflow into managed flow.
How it works
Two modes over the lean/continuous-improvement canon. five_whys runs a structured root-cause drill-down (cause vs symptom, with countermeasures, flagging shallow traps); kanban designs a board with WIP limits and the flow metrics to track; fishbone maps an Ishikawa cause diagram (6M bones, relabeled for knowledge work) with per-cause evidence status and ranked root candidates each carrying a verification step. Grounded in the operational corpus with honest weak-spot flags.
You bring
{ mode: five_whys|kanban|fishbone, problem?, workflow? }
You get
five_whys → { problem_summary, why_chain[], root_causes[] (evidence · countermeasure), shallow_traps_flagged[] } · kanban → { workflow_summary, columns[] (wip_limit · rationale), flow_metrics[], notes[] }
Use it for
- →Drill a recurring release slip to its real root cause with a concrete countermeasure
- →Design a Kanban board (columns + WIP limits + flow metrics) for a 5-person support team
- →Pair with the measurement guide: stand up lead-time / cycle-time / throughput tracking on a managed board
See it work
example outputMode: five_whys — recurring problem: "Our Friday production deploys keep failing and rolling back."
Five Whys — Friday deploys keep failing
Problem: production deploys on Friday afternoons repeatedly fail and get rolled back, costing on-call weekends.
The why-chain
- Why do Friday deploys fail? Because they bundle a week's worth of merged changes into one large release.
- Why is a week of changes shipped at once? Because the team only deploys on Fridays.
- Why only Fridays? Because deploys are manual and someone has to babysit them, so they're batched to once a week.
- Why are deploys still manual? Because the release checklist was never automated after the team doubled.
- Why was it never automated? Because automation keeps losing to feature work — no owner, no slot on the roadmap.
Root causes
1. Large, infrequent batch releases. (root, not symptom)
- Evidence: failure rate scales with changeset size; small hotfix deploys mid-week rarely roll back.
- Countermeasure: deploy smaller changes more often — move toward daily/continuous deploys, drop the Friday batch.
2. No owned, automated release pipeline. (root, not symptom)
- Evidence: the manual checklist is the reason deploys are batched in the first place — it's the upstream cause.
- Countermeasure: fund a CI/CD release-automation task with a named owner and a roadmap slot.
Shallow-analysis traps flagged
- Symptom-as-cause: stopping at "deploys fail" (a symptom) and just adding more manual QA would miss the batch-size driver.
- Single-cause bias: there are two interacting roots (batch size and missing automation); fixing only one leaves the failure mode intact.
- Stopped too early: "ban Friday deploys" treats the calendar, not the batching-and-manual-process cause underneath.
Grounded in: lean / continuous-improvement canon (systems cluster).
Run it on your data
Call it on your own inputs — over the API, or hand it to your AI agent via MCP. Discovery is open; running it is metered.