continuous_improvement_kaizen v1.0.0

---

name: "continuous_improvement_kaizen" description: "Run kaizen improvement cycles in a small team: waste walks, an improvement board, small experiments with before and after measures, and a weekly review cadence. Use when a team wants to start or fix continuous improvement, run a kaizen event, find waste in a process, set up a gemba or waste walk, or turn scattered fix ideas into measured experiments that get standardized or dropped."

---

Continuous Improvement Kaizen

Purpose

Kaizen is continuous improvement built from small changes made by the people who do the work. One big redesign every year loses to ten small tested changes a month, because the small ones get checked against real numbers and either stick or get dropped fast.

This skill runs the whole loop for a small team, roughly 3 to 15 people:

• Walk the work and name the waste in plain terms
• Put every idea on one visible board with an owner
• Test one change at a time as a small experiment with a before measure and a prediction
• Check the after measure against the prediction
• Standardize what worked, drop what did not, and start the next cycle

It covers two modes. Daily kaizen is the steady drip of small experiments. A kaizen event is a focused burst, usually a few days to a week, on one process, followed by a 30 day action list. Most small teams need daily kaizen first. An event without the weekly habit behind it fades in a month.

Workflow

1. Pick one process and one measure

• Choose a process the team touches every week and can change without asking three other teams. Onboarding replies, ticket triage, order packing, code review, invoice handling: any repeated work counts.

• Name the customer of the process, internal counts. State what good output looks like for that customer in one sentence.

• Pick one primary measure before changing anything: cycle time, wait time, defect or rework rate, touches per item, or cost per item. Add one guardrail measure that must not get worse, usually quality or workload.

• Record the baseline honestly. Measure at least 10 items or one full week, whichever gives the steadier picture. A baseline from memory is not a baseline.

2. Run a waste walk

• Go to where the work happens and watch it happen. That place is the gemba. For remote or desk work, the gemba is the live queue, the shared doc, the call recording, the actual screen, not a slide about the process.

• Walk in the order work flows, from the customer back to the start if you can. Time each step if time matters. Ask the people doing the work what stops them, what they wait for, and what they redo. Show respect means you ask and listen, you do not audit people.

• Tag what you see with the seven wastes. The list comes from Taiichi Ohno and the Toyota Production System:

1. Overproduction: making more, earlier, or faster than the next step needs
2. Waiting: people or items sitting idle for input, approval, or a machine
3. Transport: moving items or information farther or more often than needed
4. Over-processing: doing more work on an item than the customer asked for
5. Inventory: piles of unfinished or unused items, tickets, or stock
6. Motion: people moving without adding value, hunting for tools or files
7. Defects: errors that need rework, correction, or an apology

• Many teams add an eighth: unused talent, people whose knowledge never gets asked. Use it if it helps, and know it is a later addition, not part of the original seven.

• Write each finding as one line: step, waste type, what you counted or timed, how often it happens. Feelings go in as questions to measure next, not as findings.

• Full walk sheet is in references/waste-walk-and-board.md.

3. Set up the improvement board

• One board, physical or digital, where the whole team can see it without opening a private file. Four columns are enough:

• Ideas: every suggestion, dated, with the name of the person who raised it
• Testing: the one to three experiments running now, each with an owner and a check date
• Checking: experiments past their check date, waiting on the weekly review call
• Standardized: changes that passed, with the date the standard work was updated

• Cap Testing at three. A board with twelve running experiments has zero running experiments, it has twelve stalled ones.

• Every card in Testing carries: problem in one line, waste type, change being tested, owner, baseline, prediction, check date. A card missing the baseline or the prediction goes back to Ideas until it has both.

4. Run each change as a PDCA experiment

PDCA is Plan, Do, Check, Act, the four step cycle described by ASQ for carrying out change:

• Plan. State the problem from the walk data, pick one likely cause, and write the countermeasure as a small change to one step. Write a numeric prediction: what the measure will be, by when. Example: review wait drops from 26 hours median to under 12 hours in two weeks.

• Do. Run the change on a small scale first: one person, one shift, one queue, one week. Keep everything else the same so the result means something. Note what actually happened, including the workarounds people invented.

• Check. Measure the same way you measured the baseline, over a comparable window. Compare result to prediction, not to hope. Run the helper to do the math the same way every time:

  python3 scripts/kaizen.py delta --before 26 --after 11.5 --unit hours
  

It prints the absolute change, the percent change, and whether the direction is an improvement for a lower-is-better or higher-is-better measure when you pass --better lower or --better higher.

• Act. Three honest outcomes:
• Adopt: it worked. Update the standard work, train anyone affected, move the card to Standardized, and set the new baseline.
• Adapt: it helped partly or taught you something. Run a second cycle with the adjusted change.
• Abandon: it did not help or the guardrail got worse. Drop it, write one line on the card about why, and keep the card. A dropped experiment with a reason is a result, not a failure.

• Never skip Check because the change feels good. Feelings are how teams end up with five layered fixes and no idea which one helped.

5. Use 5S when the waste is in the workspace itself

When the walk keeps finding motion, inventory, and hunting for things, run a 5S pass on the physical or digital workspace:

1. Sort: remove what is not needed for current work
2. Set in order: give everything left a fixed, labeled place
3. Shine: clean the area, and treat cleaning as inspection for leaks, wear, and damage
4. Standardize: write the first three steps into a short routine with an owner
5. Sustain: check the routine on a schedule so it holds

For a digital workspace this means shared drives, ticket queues, template folders, and chat channels get the same pass: archive the dead, name the live, one home per document type.

6. Run a kaizen event when one process needs a burst

• Charter it on one page before anyone books time: event name, business case, process and scope, what is out of scope, expected results with numbers, team members, sponsor, facilitator, and dates.

• Keep the team small and cross functional: the people who do the work, one person from the step before, one from the step after, plus a sponsor who can remove blockers.

• A workable shape for a 4 to 5 day event:
• Day 1: train briefly, map the current state from a fresh walk, agree the baseline
• Day 2: pick causes, design changes, start testing the quick ones
• Day 3: keep testing, measure early results, adjust
• Day 4 or 5: report out with before and after numbers, agree the standard, list what is left

• End with a 30 day action list: each leftover item gets one named owner and a due date. Review it weekly for those 30 days. Items still open at day 30 go back to the board as normal cards, they do not get a quiet extension.

• Event runbook detail is in references/event-runbook.md.

7. Hold the weekly review cadence

• One meeting, 30 minutes, same time each week, standing at the board if you can:
• 5 minutes: primary measure and guardrail, this week against baseline, plotted as a simple run chart
• 10 minutes: experiments in Checking get their Act call in the room: adopt, adapt, or abandon
• 10 minutes: experiments in Testing report blockers only, plus any card past its check date
• 5 minutes: pick the next experiment from Ideas using impact and effort scoring

• Score candidate ideas before arguing about them:

  python3 scripts/kaizen.py score --impact 4 --effort 2 --confidence 3
  

Impact and confidence run 1 to 5, effort runs 1 to 5 where 5 is hardest. The score favors high impact, high confidence, low effort. Full scoring rules are in references/waste-walk-and-board.md.

• Daily, keep it light: a 5 minute check at the board or in the team channel for abnormalities only. Did anything break, block, or pile up yesterday. No problem solving in the daily check, items go on the board.

• Monthly, step back for 45 minutes: which measures moved over the month, which process is now the worst one, and whether the board cap and cadences still fit.

8. Standardize so gains hold

• Standard work is the current best known way, written down where the work happens: steps, order, timing or limits, and the check that catches the common error.

• Keep it to one page or one screen. If nobody can follow it without asking, it is documentation, not standard work.

• When a standard changes, date it and note which experiment changed it. Old versions get archived, not deleted, so a regression can be traced.

• Audit lightly: once a month, watch the process once and compare what happens to the standard. Gaps mean either the standard is wrong or training missed. Both are board cards, neither is a blame session.

Worked example

A six person support team. Primary measure: median first response wait. Guardrail: reopen rate.

Baseline week: median wait 26 hours, reopen rate 8 percent across 214 tickets.

Waste walk findings:

• Waiting: tickets sat in an unassigned queue until a lead sorted them each morning
• Defects: 1 in 5 tickets lacked the plan or version info agents needed, so agents replied asking for it and the clock kept running
• Over-processing: every reply, including one line answers, needed a second person to approve it

Experiment 1, Plan: auto assign new tickets round robin at arrival and add two required intake fields. Prediction: median wait under 12 hours in two weeks, reopen rate no worse than 9 percent. Do: two agents, one queue, two weeks. Check: median wait 11.5 hours, reopen rate 8 percent. Delta is a 55.8 percent cut in wait. Act: adopt, standard work for triage updated and dated, new baseline 11.5 hours.

Experiment 2, Plan: drop approval for replies under three lines using a fixed template list. Prediction: touches per ticket from 2.4 to under 1.8. Check: touches 1.7, but reopen rate rose to 11 percent on templated replies. Guardrail failed. Act: adapt, templates kept, approval dropped only for two named reply types, second cycle planned.

Two cycles, one adopted, one adapted, both decided on numbers the team collected itself. That is the system working at its normal size.

Output Contract

Every kaizen run through this skill produces:

• A dated waste walk sheet: process, steps observed, findings tagged by waste type, with counts or times
• A board snapshot: cards by column, with owners, baselines, predictions, and check dates for anything in Testing
• One experiment record per change: Plan with numeric prediction, Do notes, Check with before and after measured the same way, and the Act call with its reason
• An updated standard work note for every adopted change, with the date and the experiment that caused it
• A weekly review note: measure against baseline, Act calls made, blockers, and the next experiment chosen

Use the templates in references/templates.md so records from different weeks line up and can be compared.

Operating Rules

• Measure before and after the same way. Changing the ruler mid experiment voids the result.
• One change per experiment. Bundled changes cannot be credited or blamed, and they cannot be partly kept.
• Small and reversible beats large and permanent while you are still learning the process. Prefer a test that can be undone in a day.
• The people who do the work design the change. A fix handed down without them gets worked around, and the workaround becomes the real process.
• Blame the process in the room. Walk notes name steps and queues, not people.
• No experiment runs without a check date. Open ended trials drift into permanent half adopted changes.
• A result that misses its prediction still counts if it was measured honestly. Record it, learn from it, move on.
• Keep the board visible and the cap real. Hidden boards and uncapped work in progress are the two most common ways this system dies in small teams.
• Do not invent baseline numbers, targets from standards, or savings figures. If a number was not measured or cited, label it as a team chosen target.