Kaizen Continuous Improvement

Template Overview

Dramatic operational improvements rarely stem from massive corporate reorganizations; they emerge from compounding small, continuous refinements to daily habits and tooling. The Kaizen Continuous Improvement template helps engineering teams identify friction, formulate lean hypotheses, and standardize proven solutions in Markdown.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "Kaizen Improvement: [Waste / Friction Area]"
date: [YYYY-MM-DD]
champion: "[[Continuous Improvement Champion]]"
team: "Core Engineering & Release"
waste_category: "Waiting / Over-Processing / Motion / Defect"
experiment_duration: "2-Week Rapid Experiment"
tags: [kaizen, continuous-improvement, lean, devops, productivity]
---

# Kaizen Improvement — [Waste / Friction Area]

## 1. Problem Statement & Waste Identification
- **Observed Friction:** Pull requests frequently sit in the review queue for 36 to 48 hours awaiting second-reviewer approval.
- **Lean Waste Category:** *Waiting (Lag Time)* and *Context Switching (Inventory)*.
- **Root Friction:** Engineers lack clarity on when reviewers are focused on coding versus reviewing, leading to batch review delays.

## 2. Baseline Measurement & Success Metric
| Metric | Baseline (Pre-Kaizen) | Target Goal | Post-Experiment Result |
|---|---|---|---|
| **Median PR Review Latency** | 38 Hours | < 12 Hours | [To Measure] |
| **Average PR Size (LOC)** | 480 Lines | < 200 Lines | [To Measure] |
| **Reviewer Turnaround Cycles** | 2.8 Cycles | < 1.5 Cycles | [To Measure] |

## 3. The Kaizen Countermeasure Experiment
### Hypothesis
"If we break features into atomic pull requests (< 200 lines) and designate a shared 30-minute afternoon PR review block, median review latency will drop below 12 hours without interrupting morning deep work."

### Standardized Changes Enforced
1. **Atomic PR Rule:** Automated CI warning when a non-documentation pull request exceeds 250 lines.
2. **Review Window:** 14:00 to 14:30 daily designated for clearing the active pull request queue.

## 4. Retrospective Evaluation & Standardized Adoption
- **Was the hypothesis validated?** [Yes / No / In Progress]
- **Standardization Action:** If successful, document the atomic PR guideline in [[Engineering Team Standards]].

## 5. Next Kaizen Review Checkpoint
Review retrospective data at next sprint retrospective on **[YYYY-MM-DD]**.

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "Kaizen: Automated Gate Checking"
date: 2026-10-06
champion: "[[Alex Chen]]"
waste_category: "Defect / Rework"
tags: [kaizen, continuous-improvement]
---

# Kaizen: Automated Gate Checking

## 1. Problem
Manual verification of 24 SEO gates before deploying took 45 minutes per release and occasionally allowed subtle placeholder leaks.

## 2. Countermeasure
Implemented `scripts/seo-check.mjs` running in 3 seconds as a pre-commit hook. Reduced pre-deployment verification time from 45 minutes to 3 seconds with 0 defect leaks.

When to Use and When to Avoid

When to Use

• Use when tackling persistent, small operational frictions that slow down developer momentum.
• Use to design structured, time-boxed experiments with clear quantitative baselines.
• Use to formalize proven productivity practices into team engineering guidelines.

When to Avoid

• Avoid using for emergency incident triage during an ongoing outage.
• Avoid using for massive multi-year architectural overhauls.

On-Device AI Integration

Summarize your recording in Oyma with this local instruction:

Analyze the Kaizen continuous improvement discussion:
1. Summarize the workflow friction identified and its corresponding lean waste category.
2. Outline baseline metrics, proposed experimental countermeasures, and success targets.
3. List standardization actions and retrospective check-in dates into structured Markdown.

Your data remains securely on your Mac with zero cloud exposure.