adapt-best-practice

Adapt Best Practice

Customize a practice for specific constraints while preserving its core effectiveness.

Why This Is Best Practice

Adopted by: Situational Leadership (Hersey & Blanchard, 1969) is the canonical model for context-sensitive application — the same leadership approach applied uniformly across different team maturities produces worse outcomes than adapting to the situation. Lean manufacturing explicitly distinguishes between principles (non-negotiable) and tools (adapt to context) — Toyota Production System practitioners are trained to identify which is which before adapting. Contextual design methodology (Beyer & Holtzblatt, 1997) formalizes user-centered adaptation for design processes. Impact: Organizations that apply best practices without adaptation to their context show lower adoption and higher abandonment rates than those that receive context-appropriate versions (McKinsey Organizational Health research, 2017). The most common reason practitioners abandon practices is "it doesn't fit how we work" — which usually means the form, not the substance, was incompatible. Adaptation preserves adoption. Why best: The alternative — "apply the canonical practice or don't apply it" — produces two failure modes: abandonment when constraints make full compliance impossible, and compliance theater when people go through the motions without the core substance. Explicit Core/Adjustable/Optional classification makes the difference visible: what must stay, what can flex, and what can be skipped without breaking the practice's fundamental value.

Sources: Hersey & Blanchard (1969) "Management of Organizational Behavior"; Womack & Jones (1996) "Lean Thinking"; McKinsey Organizational Health Index research

Steps

Step 1: Identify the practice and constraints

From user input: "apply X but we're a 2-person team", "we're in a regulated industry", "we don't have budget for Y", "our team is new to this."

If the practice is named, match against installed skills. Missing-practice fallback: If the named practice does not exist in the installed skills index, do not invent one. Output:

Practice not found: [practice-name]
Closest match: [similar-skill-name] ([domain]) — is this what you meant?

If no close match exists: 'No installed practice matches [practice-name]. Run /discover-best-practices to find available practices for [domain].'

Do not proceed with adaptation until the source practice is confirmed.

If constraints aren't stated, ask ONE question:

What's the main constraint that makes the standard approach difficult?

Common constraint categories to listen for:

• Team size (solo / small team / large org)
• Industry regulation (healthcare, finance, legal, government)
• Budget / resource limits
• Technical maturity (beginner / intermediate / expert)
• Technology stack constraints
• Organizational culture (startup / enterprise / non-profit)
• Timeline pressure (needs to work this week, not this quarter)

Step 2: Classify each step of the practice

Read the matched skill's Steps section. For each step, classify:

Type	Definition
Core	Non-negotiable — removing this breaks the practice's fundamental effectiveness. The reason the practice exists.
Adjustable	Can be scaled, simplified, substituted, or done differently without losing core value. The form can change; the substance stays.
Optional	Adds value in the ideal case but can be skipped under constraints without undermining the core outcome.

Classification rubric:

• Core — step directly implements the practice's defining principle; removing it means the practice is no longer being applied (e.g., in TDD: 'write the test before the code' is Core — without it, it's not TDD)
• Adjustable — step implements the principle but the mechanism can vary by context (e.g., naming conventions, tool choices, team size thresholds)
• Optional — step adds quality or polish; the practice works correctly without it (e.g., adding inline comments, creating summary reports)

Test: ask 'If I remove this step, is the practice still being applied?' Yes → Optional or Adjustable. No → Core.

Core-step confirmation: Before adapting, explicitly state which steps are core (must be preserved) and which are context-specific (can be adapted). Show this to the user:

Core steps (preserved): [list]
Adaptable steps (context-specific): [list]
Adapting: [what will change and why]

This makes the adaptation principled rather than arbitrary — the user can see what's being treated as non-negotiable.

Step 3: Map constraints to adjustments

For each constraint the user has, identify:

• Which steps it affects (Core / Adjustable / Optional)
• What adaptation preserves the core while accommodating the constraint
• What is lost by the adaptation (and whether that loss is acceptable)

Present as a mapping table:

Constraint: [user's stated constraint]
  Affects: Step N ([Adjustable/Optional])
  Adaptation: [what changes]
  Trade-off: [what's lost — acceptable because: reason]

Step 4: Warn when a constraint compromises a Core step

If a constraint would require removing or fundamentally changing a Core step:

⚠ [constraint] conflicts with a core step of [practice].
Removing [step] would undermine the practice's primary value because [specific reason].
Proceed with adapted version? (y/n — or "explain the risk" for more detail)

If the user asks "explain the risk": describe the specific failure mode that occurs when this core step is skipped, with a concrete example if possible.

If all core steps would be removed by the constraints: don't adapt — redirect:

These constraints would remove all core steps of [practice].
The adapted version would not achieve [primary purpose].
Consider [alternative-practice] instead — it's designed for [constraint type].

Step 5: Present the adapted version

Show the full practice with modifications annotated inline. Every step must be labeled:

Adapted [practice-name] for [stated constraints]:

Step 1: [original step text] — ✓ unchanged
Step 2: [original step text] — adapted: [what changes and why, one line]
Step 3: [original step text] — ✗ skipped: [what's lost, why acceptable given constraint]

After the adapted version, summarize the trade-off in one sentence:

Trade-off: [what this adaptation gains] at the cost of [what it loses].

Rules

• Always label adapted steps — ✓ unchanged / adapted: / ✗ skipped — so the user knows what changed
• Never silently remove a Core step — always warn with Step 4 warning and get confirmation
• If constraints make the practice unworkable entirely, say so and redirect to an alternative
• Don't adapt to the point of inventing a new practice — if the adaptation diverges fundamentally from the original, name that explicitly
• The trade-off summary is required — don't leave the user guessing what they gave up
• Adaptation is not permission to skip hard parts — Core steps require a warning, not silent removal

Common Mistakes

Silent core step removal: quietly dropping a step that is Core is worse than not adapting at all — it creates the illusion of following the practice while missing its substance. Always warn.

Over-classifying as Optional: when uncertain, classify as Core. The cost of over-adapting (losing the practice's value) is higher than the cost of keeping a step that could technically be skipped.

Adapting form but not explaining why: "Step 2: adapted" with no explanation leaves the user unable to judge whether the adaptation is sound. Name what changes and why.

Redirecting when adaptation is possible: if even one core step can be preserved, adapt — don't give up and redirect unless all core steps are compromised.