Practice : Feature Toggles (Flags)

Purpose and Strategic Importance

Feature Toggles (also known as Feature Flags) are a technique that allows teams to enable or disable application functionality at runtime without deploying new code. They are essential for separating deployment from release, enabling teams to test features in production, control exposure, and reduce deployment risk.

Toggles empower teams to move fast while staying safe - shipping incomplete features behind flags, running experiments, and rolling out changes gradually. They also support rollback strategies by letting teams disable problematic features without reverting code.

Description of the Standard

  • Features are wrapped in toggles that can be turned on or off independently of code deployments.
  • Flags are controlled via environment-aware configuration (e.g. per environment, user group, or region).
  • All feature toggles are discoverable, traceable, and have defined owners.
  • Toggle status is visible to the team and monitored for unexpected changes.
  • Flags are regularly reviewed, with stale or deprecated toggles removed to avoid technical debt.

How to Practise This Standard (Playbook)

1. Getting Started

  • Use a simple toggle mechanism (e.g. config files, environment variables, or a SaaS feature flag tool like LaunchDarkly, Unleash, or Flagsmith).
  • Wrap risky or long-running features behind toggles - commit them to trunk early, but keep them off.
  • Store toggle configuration in source control or a centralised platform for visibility and auditability.
  • Ensure toggles are environment-aware and scoped correctly (e.g. dev-only, canary, production).

2. Scaling and Maturing

  • Use dynamic toggles that support user segmentation, time-based rollouts, or percentage-based canaries.
  • Integrate toggle status into your monitoring and alerting platforms.
  • Include toggle review as part of your Definition of Done - every flag should have an expiry or removal plan.
  • Build tooling to track toggle ownership, usage, and expiry across services.
  • Use toggles for A/B testing, kill switches, emergency rollbacks, and permission gating.

3. Team Behaviours to Encourage

  • Don’t delay integration - use flags to ship unfinished work safely.
  • Routinely clean up flags after feature stabilisation or rollback.
  • Treat toggle management as part of engineering hygiene.
  • Align flag usage with product experimentation, operations safety, and continuous delivery.

4. Watch Out For…

  • Leaving toggles in place indefinitely - this creates tech debt and logic complexity.
  • Flags that behave differently in test and production environments.
  • Toggle sprawl - too many unmanaged or undocumented flags.
  • Teams using toggles without knowing who owns them or what they control.

5. Signals of Success

  • Teams ship incomplete features safely and test them in production before full release.
  • Rollback is handled by toggling off, not redeploying.
  • Toggle usage is auditable, clean, and well-understood.
  • Flags are retired after use, not left behind.
  • Feature management supports business agility and risk reduction.