kaizen:why

Five Whys Analysis Apply Five Whys root cause analysis to investigate issues by iteratively asking "why" to drill from symptoms to root causes. Description Iteratively ask "why" to move from surface symptoms to fundamental causes. Identifies systemic issues rather than quick fixes. Usage /why [issue_description] Variables ISSUE: Problem or symptom to analyze (default: prompt for input) DEPTH: Number of "why" iterations (default: 5, adjust as needed) Steps State the problem clearly Ask "Why did this happen?" and document the answer For that answer, ask "Why?" again Continue until reaching root cause (usually 5 iterations) Validate by working backwards: root cause → symptom Explore branches if multiple causes emerge Propose solutions addressing root causes, not symptoms Examples Example 1: Production Bug Problem: Users see 500 error on checkout Why 1: Payment service throws exception Why 2: Request timeout after 30 seconds Why 3: Database query takes 45 seconds Why 4: Missing index on transactions table Why 5: Index creation wasn't in migration scripts Root Cause: Migration review process doesn't check query performance Solution: Add query performance checks to migration PR template Example 2: CI/CD Pipeline Failures Problem: E2E tests fail intermittently Why 1: Race condition in async test setup Why 2: Test doesn't wait for database seed completion Why 3: Seed function doesn't return promise Why 4: TypeScript didn't catch missing return type Why 5: strict mode not enabled in test config Root Cause: Inconsistent TypeScript config between src and tests Solution: Unify TypeScript config, enable strict mode everywhere Example 3: Multi-Branch Analysis Problem: Feature deployment takes 2 hours Branch A (Build): Why 1: Docker build takes 90 minutes Why 2: No layer caching Why 3: Dependencies reinstalled every time Why 4: Cache invalidated by timestamp in Dockerfile Root Cause A: Dockerfile uses current timestamp for versioning Branch B (Tests): Why 1: Test suite takes 30 minutes Why 2: Integration tests run sequentially Why 3: Test runner config has maxWorkers: 1 Why 4: Previous developer disabled parallelism due to flaky tests Root Cause B: Flaky tests masked by disabling parallelism Solutions: A) Remove timestamp from Dockerfile, use git SHA B) Fix flaky tests, re-enable parallel test execution Notes Don't stop at symptoms; keep digging for systemic issues Multiple root causes may exist - explore different branches Document each "why" for future reference Consider both technical and process-related causes The magic isn't in exactly 5 whys - stop when you reach the true root cause Stop when you hit systemic/process issues, not just technical details Multiple root causes are common—explore branches separately If "human error" appears, keep digging: why was error possible? Document every "why" for future reference Root cause usually involves: missing validation, missing docs, unclear process, or missing automation Test solutions: implement → verify symptom resolved → monitor for recurrence