Smart Analysis

Intelligently select and apply the most appropriate Kaizen analysis technique based on what you're analyzing.

Description

Analyzes context and chooses best method: Gemba Walk (code exploration), Value Stream Mapping (workflow/process), or Muda Analysis (waste identification). Guides you through the selected technique.

Usage

/analyse [target_description]

Examples:

• /analyse authentication implementation

• /analyse deployment workflow

• /analyse codebase for inefficiencies

Variables

• TARGET: What to analyze (default: prompt for input)

• METHOD: Override auto-selection (gemba, vsm, muda)

Method Selection Logic

Gemba Walk → When analyzing:

• Code implementation (how feature actually works)

• Gap between documentation and reality

• Understanding unfamiliar codebase areas

• Actual vs. assumed architecture

Value Stream Mapping → When analyzing:

• Workflows and processes (CI/CD, deployment, development)

• Bottlenecks in multi-stage pipelines

• Handoffs between teams/systems

• Time spent in each process stage

Muda (Waste Analysis) → When analyzing:

• Code quality and efficiency

• Technical debt

• Over-engineering or duplication

• Resource utilization

Steps

• Understand what's being analyzed

• Determine best method (or use specified method)

• Explain why this method fits

• Guide through the analysis

• Present findings with actionable insights

Method 1: Gemba Walk

"Go and see" the actual code to understand reality vs. assumptions.

When to Use

• Understanding how feature actually works

• Code archaeology (legacy systems)

• Finding gaps between docs and implementation

• Exploring unfamiliar areas before changes

Process

• Define scope: What code area to explore

• State assumptions: What you think it does

• Observe reality: Read actual code

• Document findings:

• Entry points

• Actual data flow

• Surprises (differs from assumptions)

• Hidden dependencies

• Undocumented behavior

• Identify gaps: Documentation vs. reality

• Recommend: Update docs, refactor, or accept

Example: Authentication System Gemba Walk

SCOPE: User authentication flow

ASSUMPTIONS (Before): • JWT tokens stored in localStorage • Single sign-on via OAuth only • Session expires after 1 hour • Password reset via email link

GEMBA OBSERVATIONS (Actual Code):

Entry Point: /api/auth/login (routes/auth.ts:45) ├─> AuthService.authenticate() (services/auth.ts:120) ├─> UserRepository.findByEmail() (db/users.ts:67) ├─> bcrypt.compare() (services/auth.ts:145) └─> TokenService.generate() (services/token.ts:34)

Actual Flow:

1. Login credentials → POST /api/auth/login
2. Password hashed with bcrypt (10 rounds)
3. JWT generated with 24hr expiry (NOT 1 hour!)
4. Token stored in httpOnly cookie (NOT localStorage)
5. Refresh token in separate cookie (15 days)
6. Session data in Redis (30 days TTL)

SURPRISES: ✗ OAuth not implemented (commented out code found) ✗ Password reset is manual (admin intervention) ✗ Three different session storage mechanisms:

• Redis for session data
• Database for "remember me"
• Cookies for tokens ✗ Legacy endpoint /auth/legacy still active (no auth!) ✗ Admin users bypass rate limiting (security issue)

GAPS: • Documentation says OAuth, code doesn't have it • Session expiry inconsistent (docs: 1hr, code: 24hr) • Legacy endpoint not documented (security risk) • No mention of "remember me" in docs

RECOMMENDATIONS:

1. HIGH: Secure or remove /auth/legacy endpoint
2. HIGH: Document actual session expiry (24hr)
3. MEDIUM: Clean up or implement OAuth
4. MEDIUM: Consolidate session storage (choose one)
5. LOW: Add rate limiting for admin users

Example: CI/CD Pipeline Gemba Walk

SCOPE: Build and deployment pipeline

ASSUMPTIONS: • Automated tests run on every commit • Deploy to staging automatic • Production deploy requires approval

GEMBA OBSERVATIONS:

Actual Pipeline (.github/workflows/main.yml):

1. On push to main: ├─> Lint (2 min) ├─> Unit tests (5 min) [SKIPPED if "[skip-tests]" in commit] ├─> Build Docker image (15 min) └─> Deploy to staging (3 min)

2. Manual trigger for production: ├─> Run integration tests (20 min) [ONLY for production!] ├─> Security scan (10 min) └─> Deploy to production (5 min)

SURPRISES: ✗ Unit tests can be skipped with commit message flag ✗ Integration tests ONLY run for production deploy ✗ Staging deployed without integration tests ✗ No rollback mechanism (manual kubectl commands) ✗ Secrets loaded from .env file (not secrets manager) ✗ Old "hotfix" branch bypasses all checks

GAPS: • Staging and production have different test coverage • Documentation doesn't mention test skip flag • Rollback process not documented or automated • Security scan results not enforced (warning only)

RECOMMENDATIONS:

1. CRITICAL: Remove test skip flag capability
2. CRITICAL: Migrate secrets to secrets manager
3. HIGH: Run integration tests on staging too
4. HIGH: Delete or secure hotfix branch
5. MEDIUM: Add automated rollback capability
6. MEDIUM: Make security scan blocking

Method 2: Value Stream Mapping

Map workflow stages, measure time/waste, identify bottlenecks.

When to Use

• Process optimization (CI/CD, deployment, code review)

• Understanding multi-stage workflows

• Finding delays and handoffs

• Improving cycle time

Process

• Identify start and end: Where process begins and ends

• Map all steps: Including waiting/handoff time

• Measure each step:

• Processing time (work happening)

• Waiting time (idle, blocked)

• Who/what performs step

• Calculate metrics:

• Total lead time

• Value-add time vs. waste time

• % efficiency (value-add / total time)

• Identify bottlenecks: Longest steps, most waiting

• Design future state: Optimized flow

• Plan improvements: How to achieve future state

Example: Feature Development Value Stream Map

CURRENT STATE: Feature request → Production

Step 1: Requirements Gathering ├─ Processing: 2 days (meetings, writing spec) ├─ Waiting: 3 days (stakeholder review) └─ Owner: Product Manager

Step 2: Design ├─ Processing: 1 day (mockups, architecture) ├─ Waiting: 2 days (design review, feedback) └─ Owner: Designer + Architect

Step 3: Development ├─ Processing: 5 days (coding) ├─ Waiting: 2 days (PR review queue) └─ Owner: Developer

Step 4: Code Review ├─ Processing: 0.5 days (review) ├─ Waiting: 1 day (back-and-forth changes) └─ Owner: Senior Developer

Step 5: QA Testing ├─ Processing: 2 days (manual testing) ├─ Waiting: 1 day (bug fixes, retest) └─ Owner: QA Engineer

Step 6: Staging Deployment ├─ Processing: 0.5 days (deploy, smoke test) ├─ Waiting: 2 days (stakeholder UAT) └─ Owner: DevOps

Step 7: Production Deployment ├─ Processing: 0.5 days (deploy, monitor) ├─ Waiting: 0 days └─ Owner: DevOps

─────────────────────────────────────── METRICS: Total Lead Time: 22.5 days Value-Add Time: 11.5 days (work) Waste Time: 11 days (waiting) Efficiency: 51%

BOTTLENECKS:

1. Requirements review wait (3 days)
2. Development time (5 days)
3. Stakeholder UAT wait (2 days)
4. PR review queue (2 days)

WASTE ANALYSIS: • Waiting for reviews/approvals: 9 days (82% of waste) • Rework due to unclear requirements: ~1 day • Manual testing time: 2 days

FUTURE STATE DESIGN:

Changes:

1. Async requirements approval (stakeholders have 24hr SLA)
2. Split large features into smaller increments
3. Automated testing replaces manual QA
4. PR review SLA: 4 hours max
5. Continuous deployment to staging (no approval)
6. Feature flags for production rollout (no wait)

Projected Future State: Total Lead Time: 9 days (60% reduction) Value-Add Time: 8 days Waste Time: 1 day Efficiency: 89%

IMPLEMENTATION PLAN: Week 1: Set review SLAs, add feature flags Week 2: Automate test suite Week 3: Enable continuous staging deployment Week 4: Train team on incremental delivery

Example: Incident Response Value Stream Map

CURRENT STATE: Incident detected → Resolution

Step 1: Detection ├─ Processing: 0 min (automated alert) ├─ Waiting: 15 min (until someone sees alert) └─ System: Monitoring tool

Step 2: Triage ├─ Processing: 10 min (assess severity) ├─ Waiting: 20 min (find right person) └─ Owner: On-call engineer

Step 3: Investigation ├─ Processing: 45 min (logs, debugging) ├─ Waiting: 30 min (access to production, gather context) └─ Owner: Engineer + SRE

Step 4: Fix Development ├─ Processing: 60 min (write fix) ├─ Waiting: 15 min (code review) └─ Owner: Engineer

Step 5: Deployment ├─ Processing: 10 min (hotfix deploy) ├─ Waiting: 5 min (verification) └─ Owner: SRE

Step 6: Post-Incident ├─ Processing: 20 min (update status, notify) ├─ Waiting: 0 min └─ Owner: Engineer

─────────────────────────────────────── METRICS: Total Lead Time: 230 min (3h 50min) Value-Add Time: 145 min Waste Time: 85 min (37%)

BOTTLENECKS:

1. Finding right person (20 min)
2. Gaining production access (30 min)
3. Investigation time (45 min)

IMPROVEMENTS:

1. Slack integration for alerts (reduce detection wait)
2. Auto-assign by service owner (no hunt for person)
3. Pre-approved prod access for on-call (reduce wait)
4. Runbooks for common incidents (faster investigation)
5. Automated rollback for deployment incidents

Projected improvement: 230min → 120min (48% faster)

Method 3: Muda (Waste Analysis)

Identify seven types of waste in code and development processes.

When to Use

• Code quality audits

• Technical debt assessment

• Process efficiency improvements

• Identifying over-engineering

The 7 Types of Waste (Applied to Software)

1. Overproduction: Building more than needed

• Features no one uses

• Overly complex solutions

• Premature optimization

• Unnecessary abstractions

2. Waiting: Idle time

• Build/test/deploy time

• Code review delays

• Waiting for dependencies

• Blocked by other teams

3. Transportation: Moving things around

• Unnecessary data transformations

• API layers with no value add

• Copying data between systems

• Repeated serialization/deserialization

4. Over-processing: Doing more than necessary

• Excessive logging

• Redundant validations

• Over-normalized databases

• Unnecessary computation

5. Inventory: Work in progress

• Unmerged branches

• Half-finished features

• Untriaged bugs

• Undeployed code

6. Motion: Unnecessary movement

• Context switching

• Meetings without purpose

• Manual deployments

• Repetitive tasks

7. Defects: Rework and bugs

• Production bugs

• Technical debt

• Flaky tests

• Incomplete features

Process

• Define scope: Codebase area or process

• Examine for each waste type

• Quantify impact (time, complexity, cost)

• Prioritize by impact

• Propose elimination strategies

Example: API Codebase Waste Analysis

SCOPE: REST API backend (50K LOC)

1. OVERPRODUCTION Found: • 15 API endpoints with zero usage (last 90 days) • Generic "framework" built for "future flexibility" (unused) • Premature microservices split (2 services, could be 1) • Feature flags for 12 features (10 fully rolled out, flags kept)

   Impact: 8K LOC maintained for no reason Recommendation: Delete unused endpoints, remove stale flags

2. WAITING Found: • CI pipeline: 45 min (slow Docker builds) • PR review time: avg 2 days • Deployment to staging: manual, takes 1 hour

   Impact: 2.5 days wasted per feature Recommendation: Cache Docker layers, PR review SLA, automate staging

3. TRANSPORTATION Found: • Data transformed 4 times between DB and API response: DB → ORM → Service → DTO → Serializer • Request/response logged 3 times (middleware, handler, service) • Files uploaded → S3 → CloudFront → Local cache (unnecessary)

   Impact: 200ms avg response time overhead Recommendation: Reduce transformation layers, consolidate logging

4. OVER-PROCESSING Found: • Every request validates auth token (even cached) • Database queries fetch all columns (SELECT *) • JSON responses include full object graphs (nested 5 levels) • Logs every database query in production (verbose)

   Impact: 40% higher database load, 3x log storage Recommendation: Cache auth checks, selective fields, trim responses

5. INVENTORY Found: • 23 open PRs (8 abandoned, 6+ months old) • 5 feature branches unmerged (completed but not deployed) • 147 open bugs (42 duplicates, 60 not reproducible) • 12 hotfix commits not backported to main

   Impact: Context overhead, merge conflicts, lost work Recommendation: Close stale PRs, bug triage, deploy pending features

6. MOTION Found: • Developers switch between 4 tools for one deployment • Manual database migrations (error-prone, slow) • Environment config spread across 6 files • Copy-paste secrets to .env files

   Impact: 30min per deployment, frequent mistakes Recommendation: Unified deployment tool, automate migrations

7. DEFECTS Found: • 12 production bugs per month • 15% flaky test rate (wasted retry time) • Technical debt in auth module (refactor needed) • Incomplete error handling (crashes instead of graceful)

   Impact: Customer complaints, rework, downtime Recommendation: Stabilize tests, refactor auth, add error boundaries

─────────────────────────────────────── SUMMARY

Total Waste Identified: • Code: 8K LOC doing nothing • Time: 2.5 days per feature • Performance: 200ms overhead per request • Effort: 30min per deployment

Priority Fixes (by impact):

1. HIGH: Automate deployments (reduces Motion + Waiting)
2. HIGH: Fix flaky tests (reduces Defects)
3. MEDIUM: Remove unused code (reduces Overproduction)
4. MEDIUM: Optimize data transformations (reduces Transportation)
5. LOW: Triage bug backlog (reduces Inventory)

Estimated Recovery: • 20% faster feature delivery • 50% fewer production issues • 30% less operational overhead

Notes

• Method selection is contextual—choose what fits best

• Can combine methods (Gemba Walk → Muda Analysis)

• Start with Gemba Walk when unfamiliar with area

• Use VSM for process optimization

• Use Muda for efficiency and cleanup

• All methods should lead to actionable improvements

• Document findings for organizational learning

• Consider using /analyse-problem (A3) for comprehensive documentation of findings