lifecycle-adoption

Original source / Raw SKILL.md

---
name: lifecycle-adoption
description: Use when starting new projects with CMMI, adding CMMI to active development, preparing for audits, migrating tools, or facing team resistance to process adoption
---

# Lifecycle Adoption

## Overview

This skill guides **incremental CMMI adoption** on existing projects without halting development. Whether you're starting a new project with CMMI from day one or retrofitting practices onto a 5-year-old codebase, this skill provides strategies for:

- **Parallel tracks adoption**: New work follows new process, legacy code exempt
- **Retrofitting existing systems**: Adding traceability, CM, testing, and metrics to running projects
- **Change management**: Overcoming team resistance and executive skepticism
- **Right-sizing practices**: Scaling from 2-person teams to large organizations
- **Managing transitions**: Tool migrations, process changes, audit preparation

**Reference**: See `docs/sdlc-prescription-cmmi-levels-2-4.md` Section 9 (Adoption Guide) for complete policy.

### When to Use This Skill

Use this skill when:

- **Starting new project**: Bootstrapping CMMI Level 2/3/4 from day one
- **Mid-project adoption**: Adding CMMI to active development without stopping
- **Audit preparation**: Retrofitting traceability/documentation for upcoming compliance review
- **Tool migration**: Changing platforms (GitHub ↔ Azure DevOps) while maintaining compliance
- **Team resistance**: Developers push back on "process overhead"
- **Executive skepticism**: Need to demonstrate ROI for CMMI investment

### What This Skill Covers

**High-Level Guidance:**
- The Parallel Tracks Strategy (don't stop development)
- Incremental vs. Big Bang Adoption
- Quick Wins vs. Foundational Practices
- Team Size Adaptations (2 developers to 50+)

**Reference Sheets (On-Demand):**
1. **Maturity Assessment** - Gap analysis, current state mapping, prioritization
2. **Incremental Adoption Roadmap** - Phased rollout, pilot projects, scaling strategies
3. **Retrofitting Requirements** - Adding traceability to existing features
4. **Retrofitting Configuration Management** - Adopting branching strategies mid-project
5. **Retrofitting Quality Practices** - Adding tests and reviews to legacy code
6. **Retrofitting Measurement** - Establishing baselines without historical data
7. **Managing the Transition** - Parallel operations, migration strategies, preserving compliance
8. **Change Management** - Team buy-in, executive sponsorship, demonstrating value

---

## High-Level Guidance

### The Parallel Tracks Strategy

**The Core Principle**: You don't need to stop development to adopt CMMI. Use parallel tracks:

```
┌─────────────────────────────────────────────────────────┐
│ NEW FEATURES (Follow New Process)                       │
│ - Requirements tracked in issues                        │
│ - ADRs for design decisions                            │
│ - PR reviews required                                   │
│ - Test coverage enforced                                │
│ - Full CMMI compliance                                  │
└─────────────────────────────────────────────────────────┘
                           │
                           │ Parallel Development
                           │
┌─────────────────────────────────────────────────────────┐
│ EXISTING CODE (Exempt from Retrofit)                    │
│ - Legacy code untouched unless modified                │
│ - Bug fixes follow minimal process                     │
│ - Critical paths retrofitted selectively               │
│ - No "rewrite everything" required                     │
└─────────────────────────────────────────────────────────┘
```

**Timeline**: 2-3 months to full adoption for typical team (5-10 developers)

**Benefits**:
- ✅ Development velocity maintained
- ✅ Team learns gradually (not overwhelmed)
- ✅ Quick wins demonstrate value
- ✅ Audit trail created going forward

**Anti-Pattern**: "Big Bang Adoption" - Trying to go from Level 1 to Level 3 overnight. Result: Development freeze, team revolt, incomplete implementation.

### Incremental vs. Big Bang Adoption

| Aspect | Big Bang (❌ Anti-Pattern) | Incremental (✅ Recommended) |
|--------|---------------------------|------------------------------|
| **Timeline** | "We're Level 3 starting Monday!" | 2-3 month phased rollout |
| **Development** | Freeze while implementing | Parallel tracks, continuous shipping |
| **Team reaction** | Overwhelm, resistance | Gradual learning, buy-in |
| **Risk** | High (all-or-nothing) | Low (course corrections possible) |
| **First milestone** | Full compliance | Quick wins (branch protection, PR reviews) |

**Why Big Bang Fails**:
1. **Cognitive overload**: 11 process areas, 100+ practices = team paralysis
2. **Business pressure**: "Why aren't we shipping?" within 2 weeks
3. **Incomplete implementation**: Rushing leads to cargo cult compliance (checklist theater)
4. **No feedback loop**: Can't learn what works for your team context

**Incremental Approach**:
1. **Week 1-2**: Quick wins (branch protection, PR templates, issue tracking)
2. **Week 3-4**: Foundation (CM workflow, basic traceability)
3. **Week 5-8**: Quality practices (test coverage, peer reviews, ADRs)
4. **Week 9-12**: Measurement (metrics collection, baselines)
5. **Month 4+**: Refinement (Level 3 enhancements, continuous improvement)

### Quick Wins vs. Foundational Practices

**Quick Wins** (implement first - immediate value):

| Practice | Time to Implement | Value |
|----------|------------------|-------|
| **Branch protection rules** | 30 minutes | Prevents force pushes, lost work |
| **PR review requirement** | 1 hour | Catches bugs before merge |
| **Issue templates** | 2 hours | Structured requirement capture |
| **CI/CD basic pipeline** | 1 day | Automated testing, faster feedback |
| **ADR template** | 1 hour | Decision documentation starts |

**Foundational Practices** (implement second - enables maturity):

| Practice | Time to Implement | Enables |
|----------|------------------|---------|
| **Requirements traceability** | 1-2 weeks | Audit trail, impact analysis |
| **Branching workflow (GitFlow/Trunk)** | 1 week + training | Release management, parallel dev |
| **Test coverage baseline** | 2-3 weeks | Quality metrics, regression prevention |
| **Metrics collection** | 2-4 weeks | Baselines, trend analysis, process improvement |
| **Risk register** | 1 week | Proactive risk management |

**Strategy**: Lead with quick wins to demonstrate value, then invest in foundations while team is bought in.

### Team Size Adaptations

**2-3 Person Team** (Minimal Viable CMMI):
- Target: Level 2 (Managed)
- **REQM**: GitHub Issues as requirements
- **CM**: Feature branches + PR review (both review each other)
- **VER**: Automated tests only, no formal test plan
- **Documentation**: Minimal (ADRs for major decisions, no formal specs)
- **Effort**: 5% of project time on process

**4-10 Person Team** (Sweet Spot):
- Target: Level 3 (Defined)
- **REQM**: Work items with acceptance criteria, RTM via tool
- **CM**: GitFlow or GitHub Flow, 2 reviewers required
- **VER**: Test coverage >80%, formal peer review checklist
- **Documentation**: Standard templates, comprehensive ADRs
- **Effort**: 10-15% of project time on process

**11-30 Person Team** (Organizational Standard):
- Target: Level 3 → Level 4
- **REQM**: Requirements templates, formal elicitation
- **CM**: Branching strategy document, release management
- **VER**: Test plans (IEEE 829), defect density tracking
- **Documentation**: Architecture review board, design reviews
- **Effort**: 15-20% of project time on process

**30+ Person Team** (Full CMMI):
- Target: Level 4 (Quantitatively Managed)
- **All Level 3 practices** +
- **Metrics**: Statistical process control, baselines, prediction models
- **Roles**: Dedicated process owner, metrics analyst
- **Effort**: 20-25% of project time on process

#### Small Team Enforcement (2-4 Person Teams)

**Problem**: Small teams lack independent oversight (no tech lead, no manager, no external review). Under deadline pressure, teams can exploit this to appear compliant while avoiding actual work.

**Solution**: See **Enforcement Mechanisms #16-20** (Small Team Enforcement section) for detailed enforcement strategies including:
- External review requirement
- Written requirements mandate
- ADR timing verification
- Solo emergency protocol
- Admin bypass audit

These mechanisms require external verification (advisor, consultant, or automation) since small teams cannot self-police.

### When NOT to Retrofit Everything

**Selective Retrofitting Principle**: Not all legacy code needs full CMMI compliance.

**DO retrofit**:
- ✅ Critical path features (security, payment processing, data integrity)
- ✅ High-change areas (frequent bugs, ongoing development)
- ✅ Audit-required components (regulated functionality)
- ✅ New features (all new work follows new process)

**DON'T retrofit**:
- ❌ Stable, low-risk code (hasn't changed in 6+ months)
- ❌ Deprecated features (scheduled for removal)
- ❌ Prototypes and throwaway code
- ❌ Well-tested legacy code with no known issues

**Risk-Based Decision Matrix**:

```
High Change Frequency │ RETROFIT    │ RETROFIT    │
                      │ (Full)      │ (Selective) │
─────────────────────┼─────────────┼─────────────┤
Low Change Frequency  │ RETROFIT    │ EXEMPT      │
                      │ (Critical)  │             │
                      └─────────────┴─────────────┘
                        High Risk     Low Risk
```

**Example**: 100 features shipped over 2 years
- **10 critical features** (payment, auth, data sync) → Full retrofit (requirements, tests, ADRs)
- **30 active features** (ongoing development) → Selective retrofit (traceability only)
- **60 stable features** (no changes in 6+ months) → Exempt (document as legacy)

**Time savings**: Retrofitting 40 features instead of 100 = 60% effort reduction

**CRITICAL: Exemption List Approval Gate**

**Enforcement**: CTO or security officer MUST approve exemption list before Week 4. This prevents managers from classifying everything as "low risk" to avoid retrofit work.

**Approval requirements**:
- [ ] Exemption list documented with rationale (feature name, why exempt, risk assessment)
- [ ] For each exempted feature: Must justify BOTH "low change frequency" AND "low risk"
- [ ] If feature handles ANY of these → Cannot be exempt without security officer approval:
  - Protected Health Information (PHI) / Personally Identifiable Information (PII)
  - Authentication or authorization
  - Payment processing
  - Audit logging
  - Encryption/decryption
- [ ] CTO sign-off required if >80% of features classified as "exempt"

**Red flags requiring escalation to executive sponsor**:
- >80% of features labeled "exempt" → Gaming detected
- All authentication features labeled "low risk" → Security misunderstanding
- Features with known vulnerabilities labeled "exempt" → Compliance violation

**Accountability**:
- Team lead must present exemption list with evidence to CTO in Week 4 review
- CTO spot-checks 10 random "exempt" features to verify classification accuracy
- If classification gaming detected → Restart with proper risk assessment

**Example compliant exemption**:
```
Feature: Legacy report generator (reports.py)
- Last changed: 18 months ago
- Risk: Low (read-only, no PII, no auth)
- Change frequency: Zero changes in 12+ months
- Status: EXEMPT (approved by CTO 2026-01-24)
```

**Example non-compliant exemption**:
```
Feature: User login endpoint (auth.py)
- Risk claimed: "Low"
- Reality: HIGH (authentication is always high risk)
- Status: CANNOT EXEMPT (handles auth → must retrofit)
```

### Common Objections and Responses

**Objection 1**: "CMMI will slow us down"

**Response**:
- Acknowledge: "Poorly implemented process DOES slow teams down. Let's avoid that."
- Show lightweight Level 2 approach (not bureaucracy)
- Quick wins demonstrate value: "Branch protection prevented 3 lost-work incidents this month"
- Data: Teams with code review find bugs 60% faster than those without (Microsoft Research)

**Objection 2**: "We're too small for CMMI"

**Response**:
- Level 2 works for 2-person teams (see Team Size Adaptations above)
- GitHub Issues + PR reviews + ADRs = minimal overhead, maximum audit trail
- Automation reduces burden (GitHub Actions, not manual checklists)
- Small teams benefit MORE from process (no redundancy to catch errors)

**Objection 3**: "We're agile, CMMI is waterfall"

**Response**:
- CMMI is methodology-agnostic (works with Scrum, Kanban, XP)
- Map CMMI to sprints: REQM in planning, VER in reviews, VAL in demos
- User stories = requirements, ADRs = design, sprint retro = process improvement
- See prescription Section 6.2 for Agile workflow mapping

**Objection 4**: "It's too late to change mid-project"

**Response**:
- Parallel tracks mean you don't change existing code
- New features follow new process starting TODAY
- Retrofitting is selective (critical paths only)
- 2-3 month transition is feasible even on 2-year-old projects

**Objection 5**: "We don't have time for this"

**Response**:
- Time pressure is exactly why you need process (reduce rework, catch bugs early)
- Quick wins (branch protection, PR reviews) take <1 day to implement
- ROI calculation: 1 hour of code review saves 5 hours of debugging (industry average)
- Audit failure costs MORE time than incremental adoption

### Red Flags: Thoughts That Mean "STOP"

If you or the user are thinking these thoughts, STOP and reconsider:

| Thought | Reality | What to Do Instead |
|---------|---------|-------------------|
| **"Let's do a big bang rollout"** | 95% failure rate for big bang CMMI adoption | Use parallel tracks: new work follows new process, old code exempt |
| **"We'll retrofit everything before starting new work"** | Analysis paralysis, development freeze | Selective retrofit (30% critical features), parallel new development |
| **"We're too small for CMMI"** | 2-person teams can do Level 2 in 1 week | Show team size adaptation table (Level 2 = minimal viable) |
| **"CMMI = waterfall, we're agile"** | CMMI is methodology-agnostic | Map CMMI to sprint ceremonies (RD in planning, VER in review) |
| **"Let's wait until the project is done"** | Post-hoc compliance is 10x harder | Start now with parallel tracks, minimal disruption |
| **"We need perfect compliance from day one"** | Perfectionism kills adoption | Incremental: 30% → 50% → 70% compliance over 3 months |
| **"Process first, then demonstrate value"** | Team will revolt before seeing benefits | Quick wins first (branch protection Day 1), then deeper practices |
| **"Everyone must follow the same process"** | One-size-fits-all fails | Tailoring by team size, risk, and domain |
| **"We'll add tests after the feature is done"** | "Later" = never | Require tests for all new code NOW, retrofit selectively |
| **"Management just needs to mandate it"** | Top-down mandates create cargo cult compliance | Involve team in process design, demonstrate value, then enforce |

### Rationalization Table

Common rationalizations that undermine adoption (and how to counter them):

| Rationalization | Pattern | Counter |
|----------------|---------|---------|
| **"Just this once we'll skip [practice]"** | Slippery slope | "Just this once" becomes "every time". Enforce consistently from Day 1. |
| **"We're in a hurry, no time for [practice]"** | Time pressure override | "Hurry is why we NEED process. Skipping reviews = 5x more debugging time later." |
| **"This feature is too small for [practice]"** | Scope minimization | "Small changes cause big bugs. All features follow process, no exceptions." |
| **"The process is slowing us down"** | Productivity panic | "Initial 10% slowdown, long-term 30% speedup. Measure before/after." |
| **"We already do code review informally"** | Informal = good enough | "Informal = inconsistent. 8 of last 10 PRs had no review (check GitHub)." |
| **"Our team is experienced, we don't make mistakes"** | Overconfidence | "Last month: 12 production bugs. Experience ≠ infallibility." |
| **"We'll fix the process later"** | Procrastination | "Process debt compounds like technical debt. Fix now or pay 10x later." |
| **"The audit is months away"** | Distant deadline | "Process takes 2-3 months to stabilize. Start now or fail audit." |
| **"Let's use our own process, not CMMI"** | Not invented here | "Your process likely duplicates CMMI. Map it, fill gaps, save time." |
| **"We need to finish this sprint first"** | Perpetual deferral | "Every sprint will have 'just one more thing'. Parallel tracks start TODAY." |
| **"This is too bureaucratic"** | Fear of overhead | "Level 2 = branch protection + PR template. That's not bureaucracy." |
| **"Our old process worked fine"** | Status quo bias | "13 bugs last quarter, 45% of time on rework. That's not 'fine'." |

**How to use this table:**
- When user or team member says a rationalization, identify the pattern
- Respond with the counter (data-driven, not defensive)
- Redirect to the appropriate reference sheet for concrete guidance

## Enforcement Mechanisms

**Purpose**: Prevent common loophole exploits discovered through TDD adversarial testing. These 19 mechanisms close rationalizations teams use under pressure.

**Organization**:
- **Adoption & Progression** (#1-5): Emergency bypass, progression gates, workshops, parallel tracks, early adopters
- **Requirements & Design** (#6-10): Depth, validation, coverage, traceability, discovery
- **Code Review** (#11-12): Risk assessment, quality standards
- **Small Teams** (#13-17): External review, written docs, timing, emergencies, admin access
- **Git Security** (#18-19): Fork attacks, branch protection

---

### Adoption & Progression

#### 1. Emergency Bypass Process

**Prevents**: "Just this once" excuse for skipping process

**Enforcement**:
- Emergency hotfixes STILL require 1 reviewer (4-hour async SLA)
- Tag commit `emergency-bypass`
- Post-hoc documentation within 24 hours
- Monthly review: >2/month = process problem

**Red flag**: >2 emergencies/month

#### 2. Progression Gates (Consolidated)

**Prevents**: Eternal quick-wins loop, permanent plateau

**Enforcement**:
- Week 2: Quick wins complete (branch protection, templates, 1+ bug caught)
- Week 4: Foundations started (50% traceability, 3+ ADRs, workflow documented)
- Week 8: Quality active (test coverage >60%, 100% PRs reviewed)
- Week 12: Measurement established (dashboard live, baselines calculated)
- Gate failure → CTO intervention required

**Red flag**: Still at quick wins in Month 3 → escalate

#### 3. Workshop Quality Standards

**Prevents**: Workshop theater (checkbox attendance without engagement)

**Enforcement**:
- 70% active participation (documented contributions)
- 2+ alternative approaches documented
- Post-workshop survey (70% comprehension, 50% buy-in)
- Artifacts: attendance, brainstorm notes, voting results
- CTO reviews artifacts Week 2

**Red flag**: <50% felt they could influence → repeat workshop

#### 4. Parallel Tracks Deadline

**Prevents**: Indefinite legacy exemption

**Enforcement**:
- Hard cutoff Month 2: ALL new work follows process
- Bug fix = <50 LOC change only
- Tech lead classifies work (not self-reported)
- Monthly audit: >50% "legacy" in Month 3 = gaming

**Red flag**: Work started Week 7 claimed as "legacy"

#### 5. Early Adopter Credibility

**Prevents**: Junior dev pilot theater

**Enforcement**:
- >1 year tenure required
- Team validates influence ("Who do you respect?")
- Scaling metrics: Week 4 (2-3 people), Week 8 (50%), Week 12 (80%)
- CTO reviews Month 2

**Red flag**: Pilot confined to 1-2 people Week 8

---

### Requirements & Design

#### 6. Requirement Depth Standards

**Prevents**: Shallow requirements speed run

**Enforcement**:
- 6-12 requirements per moderate feature minimum
- Tech lead reviews 20% sample
- Reject if average <5 requirements/feature
- Time calibration: 4-8 hours per feature (not negotiable)

**Red flag**: 5+ feature retrofits per day

#### 7. Stakeholder Validation Enforcement

**Prevents**: "Pending validation" indefinite deferral

**Enforcement**:
- 3 documented contact attempts required
- Escalation path to executive
- NO "pending" acceptable for audits
- Proxy validation allowed with documentation

**Red flag**: >10% "pending" at Week 4

#### 8. Level 2 vs 3 Coverage Clarification

**Prevents**: 30% escape hatch abuse

**Enforcement**:
- Determine audit level Week 0 (ask auditor)
- Level 2: 30-40% of CRITICAL features
- Level 3: 80-100% of ALL features
- Auditor decides scope, not PM

**Red flag**: PM unilaterally claims "Level 2"

#### 9. Tool-Based RTM Requirement

**Prevents**: Spreadsheet escape hatch at Level 3

**Enforcement**:
- Level 2: Spreadsheet acceptable
- Level 3: GitHub/ADO required (not spreadsheet)
- Migration timeline: Weeks 1-2 spreadsheet, Weeks 3-4 migrate, Week 5+ tool only

**Red flag**: Spreadsheet still used Month 2 for Level 3

#### 10. Dark Matter Feature Detection

**Prevents**: Hiding undocumented features from audit

**Enforcement**:
- 4-way verification: code analysis, routes, UI audit, stakeholder memory
- Cross-validate lists for discrepancies
- External reviewer spot-checks 10 random code sections

**Red flag**: Feature count suspiciously low for LOC

---

### Code Review

#### 11. Risk Assessment Authority

**Prevents**: Risk-labeling game (self-declaring "low risk")

**Enforcement**:
- Objective criteria: PII/Money/Auth = HIGH (non-negotiable)
- 2-person sign-off required for risk classification
- Security team approval to downgrade

**Red flag**: >80% features labeled "low risk"

#### 12. Review Quality Standards

**Prevents**: Rubber-stamp theater

**Enforcement**:
- Minimum 5 min per 100 LOC
- Substantive comment required (not just "LGTM")
- <2 min reviews flagged
- Monthly audit: 10% spot-check
- >20% rubber stamps → lose approval privileges 1 month

**Red flag**: 100% compliance, 0 bugs caught for 4+ weeks

---

### Small Team Enforcement (2-4 person teams)

#### 13. External Review Requirement

**Prevents**: Rubber-stamp between friends

**Enforcement**:
- Quarterly external review (10% of PRs)
- Automation BLOCKS <5 min/100 LOC reviews
- Monthly self-audit required

**Accountability**: External reviewer reports to executive

#### 14. Written Requirements Mandate

**Prevents**: Verbal-only work

**Enforcement**:
- Issue MUST exist BEFORE PR created
- Timestamp verification (Issue date < PR date)
- GitHub Action blocks PRs without linked issue

**Red flag**: >20% Issues created within 1 hour of PR

#### 15. ADR Timing Verification

**Prevents**: Backdating architectural decisions

**Enforcement**:
- ADR commit MUST precede implementation commits
- Git timestamp verification (automated check)
- Limit: 2 retroactive ADRs/quarter

**Verification**: `git log --format=%ai -- docs/adr/` vs implementation commits

#### 16. Solo Emergency Protocol

**Prevents**: Skipping review when partner unavailable

**Enforcement**:
- Preferred: 4-hour async review (phone acceptable)
- If truly solo: merge with `emergency-solo` tag, external review within 48 hours
- Limit: 1 solo emergency/quarter

**Red flag**: >4 solo emergencies/year

#### 17. Admin Bypass Audit

**Prevents**: GitHub admin bypass enabled

**Enforcement**:
- Weekly GitHub Action verifies "enforce_admins=true"
- Screenshot required for quarterly review
- Separation of duties: external admin OR weekly automation

**Verification**: `gh api repos/{owner}/{repo}/branches/main/protection | jq '.enforce_admins.enabled'`

---

### Git Workflow Security

#### 18. Fork Security Configuration

**Prevents**: Fork-based bypass attack

**Enforcement**:
- GitHub: "Restrict who can push to matching branches" enabled
- "Require linear history" enabled
- Weekly audit for force-push attempts
- Monthly manual audit of protection changes

**Red flag**: Multiple failed force-push attempts

#### 19. Emergency Hotfix Enforcement

**Prevents**: Disabling branch protection

**Enforcement**:
- Emergency does NOT mean disable protection
- 8-step process: hotfix branch → PR → 4-hour review → merge via protection
- Real-time webhook alerts if protection disabled
- Auto-remediation every 6 hours
- Mandatory post-mortem if disabled

**Red flag**: Protection disabled >1 hour

---



## Reference Sheets

The following reference sheets provide detailed, step-by-step guidance for specific adoption scenarios. Each reference is a separate file - load on-demand when needed.

### 1. Maturity Assessment (`maturity-assessment.md`)

**When to load:** Starting adoption, gap analysis, determining Level 2/3/4 fit, audit preparation

Assess current CMMI maturity level, identify gaps, prioritize improvements using:
- Process area scoring rubric (11 CMMI process areas)
- Evidence-based assessment templates
- Risk-based gap prioritization matrix (quick wins vs. foundational practices)

**Provides:** Scoring method, assessment templates, prioritization framework, tool integration patterns

**Load reference:** See `maturity-assessment.md` for complete assessment process.

---

### 2. Incremental Adoption Roadmap (`adoption-roadmap.md`)

**When to load:** Planning phased rollout, pilot project strategy, scaling practices organization-wide

12-week incremental adoption roadmap with:
- Week-by-week milestones for Level 2/3/4
- Pilot project approach (start small, scale success)
- Parallel tracks timeline (new work = new process)
- Team size adaptations (2-person to 50+ person teams)

**Provides:** Weekly implementation plans, pilot selection criteria, scaling strategies, rollout timelines

**Load reference:** See `adoption-roadmap.md` for complete phased rollout guidance.

---

### 3. Retrofitting Requirements (`retrofitting-requirements.md`)

**When to load:** Adding requirements traceability to existing features, documenting undocumented code

Add RD + REQM practices to existing codebase without rewriting:
- Dark matter feature detection (find undocumented features)
- Reverse-engineering requirements from code
- Progressive traceability (start with critical paths)
- Stakeholder validation for legacy features

**Provides:** Retrofitting workflow, traceability templates, GitHub/Azure DevOps implementation patterns

**Load reference:** See `retrofitting-requirements.md` for complete retrofitting process.

---

### 4. Retrofitting Configuration Management (`retrofitting-cm.md`)

**When to load:** Adopting branching strategies mid-project, adding version control discipline, migrating platforms

Add CM practices to existing project without disrupting active development:
- Branch strategy migration (trunk-based → GitFlow → release branches)
- Grandfathering existing violations (future-only enforcement)
- Tag/release strategy for untagged history
- Migration workflows (SVN → Git, Git → Monorepo)

**Provides:** Migration playbooks, branch protection rules, release process templates, rollback procedures

**Load reference:** See `retrofitting-cm.md` for complete CM retrofitting guidance.

---

### 5. Retrofitting Quality Practices (`retrofitting-quality.md`)

**When to load:** Adding tests and code reviews to legacy code, implementing VER + VAL practices

Add testing and review practices without "test everything first":
- Progressive test coverage (new code first, then critical paths)
- Characterization tests for legacy code
- Code review policy adoption (future PRs only)
- Validation criteria for existing features

**Provides:** Test retrofitting strategies, review policy templates, coverage targeting, validation workflows

**Load reference:** See `retrofitting-quality.md` for complete quality retrofitting process.

---

### 6. Retrofitting Measurement (`retrofitting-measurement.md`)

**When to load:** Establishing metrics without historical data, adding MA + QPM + OPP practices

Create baselines and measurement programs when starting from zero:
- Establishing baselines without history (use industry benchmarks)
- Metric selection for Level 2/3/4
- Automated data collection (GitHub API, Azure DevOps Analytics)
- Statistical baselines and control limits (Level 4)

**Provides:** Metric definitions, baseline establishment methods, dashboard templates, SPC implementation

**Load reference:** See `retrofitting-measurement.md` for complete measurement retrofitting guidance.

---

### 7. Managing the Transition (`managing-transition.md`)

**When to load:** Tool migrations, platform changes, maintaining compliance during parallel operations

Maintain CMMI compliance while changing tools/platforms:
- Parallel operations (old + new systems simultaneously)
- GitHub ↔ Azure DevOps migration patterns
- Preserving traceability during migration
- Compliance continuity strategies

**Provides:** Migration playbooks, parallel operation procedures, traceability preservation, rollback plans

**Load reference:** See `managing-transition.md` for complete transition management guidance.

---

### 8. Change Management (`change-management.md`)

**When to load:** Team resistance, executive skepticism, demonstrating ROI, building buy-in

Overcome organizational resistance and build support for CMMI adoption:
- Countering "process = overhead" objections (with data)
- Demonstrating quick wins (velocity improvement, bug reduction)
- Executive sponsorship strategies
- Team buy-in through incremental value delivery

**Provides:** Objection handling scripts, ROI calculations, stakeholder communication templates, success metrics

**Load reference:** See `change-management.md` for complete change management guidance.

---

## Loading Reference Sheets

**How to access:**
```
"I need detailed guidance on [topic]"
→ Load the appropriate reference sheet from the list above
```

**When you need a reference:**
- Be specific about which aspect you need ("gap analysis process" → maturity-assessment)
- References are comprehensive (250-550 lines each)
- Each reference is self-contained with templates and examples

**Cross-references:** Reference sheets link to each other when practices overlap (e.g., retrofitting requirements references maturity assessment for prioritization).