bradtaylorsf Continuous Improvement Skill
Patterns for implementing continuous improvement.
PDCA Cycle
Plan-Do-Check-Act
## PDCA Framework
### Plan
1. Identify improvement opportunity
2. Analyze current state
3. Define target state
4. Create action plan
### Do
1. Implement change on small scale
2. Document what happens
3. Collect data
4. Note any problems
### Check
1. Analyze results
2. Compare to target
3. Identify what worked
4. Learn from failures
### Act
1. Standardize successful changes
2. Share learnings
3. Plan next cycle
4. Abandon what didn't work
Example PDCA
## PDCA: Reduce Code Review Time
### Plan
**Problem:** Code reviews take 3+ days on average
**Target:** Reduce to < 1 day
**Root Cause:** No SLA, large PRs, unclear ownership
**Actions:**
1. Set 24-hour review SLA
2. Limit PR size to 400 lines
3. Auto-assign reviewers
### Do
**Implementation:**
- Communicated new policy
- Added PR size linting
- Set up auto-assignment bot
- Tracked metrics for 2 weeks
### Check
**Results:**
- Average review time: 3.2 days → 0.8 days ✅
- PR size: 650 lines → 280 lines
- Review quality: Maintained
- Team satisfaction: Improved
### Act
**Standardize:**
- Added to team handbook
- Created onboarding material
- Set up monitoring dashboard
- Sharing with other teams
Kaizen
Continuous Small Improvements
## Kaizen Principles
### 1. Question Everything
- Why do we do it this way?
- What problem does this solve?
- Is there a better way?
### 2. Eliminate Waste
- Remove unnecessary steps
- Automate repetitive tasks
- Reduce wait times
### 3. Empower Teams
- Everyone can suggest improvements
- No idea is too small
- Celebrate incremental progress
### 4. Go to Gemba
- Observe actual work
- Talk to people doing the work
- Understand real challenges
Kaizen Board
## Improvement Ideas Board
### Ideas (Anyone can add)
- [ ] Automate test data setup
- [ ] Add keyboard shortcuts to UI
- [ ] Simplify deployment script
### In Analysis
- [ ] Cache API responses (analyzing impact)
### In Progress
- [ ] Standardize error messages (@jane)
### Completed This Month
- [x] Add pre-commit hooks
- [x] Improve logging format
- [x] Automate dependency updates
Retrospectives
Sprint Retrospective
## Retrospective Format
### Start-Stop-Continue
**Start:** What should we start doing?
**Stop:** What should we stop doing?
**Continue:** What should we keep doing?
### 4 Ls
**Liked:** What went well?
**Learned:** What did we learn?
**Lacked:** What was missing?
**Longed For:** What do we wish we had?
### Mad-Sad-Glad
**Mad:** What frustrated us?
**Sad:** What disappointed us?
**Glad:** What made us happy?
Action Item Tracking
## Retrospective Actions
### Current Sprint Actions
| Action | Owner | Due | Status |
|--------|-------|-----|--------|
| Set up code review SLA | @jane | Jan 20 | Done |
| Add staging parallelization | @bob | Jan 25 | In Progress |
| Update onboarding docs | @alice | Jan 18 | Not Started |
### Previous Sprint Actions (Carryover)
| Action | Owner | Original Due | Status |
|--------|-------|--------------|--------|
| Improve test coverage | @charlie | Jan 5 | Delayed |
### Metrics
- Actions completed: 75%
- Average completion time: 10 days
- Carryover rate: 15%
Root Cause Analysis
5 Whys
## 5 Whys Example
**Problem:** Production deployment failed
**Why 1:** The deployment script exited with error
**Why 2:** Database migration failed
**Why 3:** Column already existed
**Why 4:** Migration was already run manually
**Why 5:** No tracking of manual changes
**Root Cause:** No process for tracking database changes
**Solution:**
- All database changes must go through migrations
- Add migration status check before deploy
- Document in runbook
Fishbone Diagram
## Fishbone Analysis: Slow Deployments
┌─────────────────┐
│ Slow Deploys │
└────────┬────────┘
│
┌────────────────────────────┼────────────────────────────┐
│ │ │
┌───┴────┐ ┌────┴────┐ ┌────┴────┐ │ People │ │ Process │ │ Tools │ ├────────┤ ├─────────┤ ├─────────┤ │ Manual │ │ Serial │ │ Old CI │ │ steps │ │ stages │ │ system │ │ │ │ │ │ │ │ Review │ │ No │ │ No │ │ delays │ │ parallel│ │ caching │ └────────┘ └─────────┘ └─────────┘
**Actions:**
- People: Automate manual steps, set review SLA
- Process: Parallelize independent stages
- Tools: Upgrade CI, implement caching
Improvement Metrics
Tracking Progress
## Improvement Metrics
### Lead Time
Time from commit to production.
Baseline: 5 days
Target: 1 day
Current: 2 days
### Deployment Frequency
How often we deploy.
Baseline: Weekly
Target: Daily
Current: Every 2 days
### Change Failure Rate
Percentage of deploys causing issues.
Baseline: 15%
Target: 5%
Current: 8%
### Mean Time to Recovery
Time to restore service after failure.
Baseline: 4 hours
Target: 30 minutes
Current: 1 hour
Trend Visualization
## Improvement Trends (6 months)
### Lead Time (days)
Jan: █████████████████████████ 5.0
Feb: ████████████████████ 4.0
Mar: ███████████████ 3.0
Apr: ███████████ 2.2
May: ██████████ 2.0
Jun: █████████ 1.8
### Deployment Frequency (per week)
Jan: ██ 1
Feb: ███ 1.5
Mar: ████ 2
Apr: ██████ 3
May: █████████ 4.5
Jun: ██████████ 5
Knowledge Sharing
Lessons Learned
## Lessons Learned Template
### Title
[Brief description of the learning]
### Context
What situation led to this learning?
### What Happened
What occurred? What was the outcome?
### Key Takeaway
What's the main lesson?
### Recommendations
What should we do differently?
### Applicable To
What other situations does this apply to?
Best Practice Documentation
## Best Practices Registry
### Development
- [ ] Feature flags for risky changes
- [ ] Trunk-based development
- [ ] Pair programming for complex features
### Testing
- [ ] Test pyramid approach
- [ ] Mutation testing for critical code
- [ ] Contract testing for APIs
### Deployment
- [ ] Blue-green deployments
- [ ] Automated rollbacks
- [ ] Gradual rollouts
### Monitoring
- [ ] SLOs with error budgets
- [ ] Distributed tracing
- [ ] Structured logging
Integration
Used by:
improvement-coordinatoragentquality-analystagent