Science Requires Enforcement
The laws of physics - Little's Law - Kingman's Formula - are descriptive. They tell us how the system behaves. Regulation is prescriptive. It tells us how to force the system to behave well. You cannot "manage" complexity with good intentions. You manage it with constraints.
As Nicole Forsgren, Jez Humble, and Gene Kim established in Accelerate:
"We found that high performers deploy more frequently, have faster lead times, and have lower change failure rates... The key is to reduce batch size and implement continuous delivery." — Forsgren, Humble, & Kim, Accelerate
We translate these physical laws into non-negotiable operational constraints. These are not "Guidelines". They are Governance.
Constraint 1: The WIP Limit (Hard Cap)
To prevent the exponential collapse of flow described by Kingman's Formula - we enforce a strict Work In Progress (WIP) Limit.
No active engineer may have more than 2 items in flight (In Progress - In Review - or Staging) at any given time. This is not an average. It is a blocking constraint.
- Mechanism: The issue tracker (Jira/Linear) is configured to physically prevent the assignment of a 3rd ticket. The "Start" button is disabled. This forces the issue.
- The "Stop Starting - Start Finishing" Protocol: If an engineer is blocked on their 2 items - they are forbidden from pulling a 3rd. They must swarm to unblock the system. Review someone else's code. Fix a broken build. Clarify a spec. This forces the team to attack Congestion rather than generating more inventory.
- Override Protocol: If a P0 production incident occurs - one active item must be formally moved to "Blocked" or "Backlog" before the P0 can be started. Capacity is finite - we do not pretend otherwise.
Constraint 2: The 24-Hour Integration Rule
To mitigate "Merge Debt" - we mandate a Maximum Branch Lifetime of 24 hours.
Jez Humble and David Farley, in Continuous Delivery, make the case for frequent integration:
"If it hurts, do it more often... Frequent integration reduces the pain of merging and ensures that the software is always in a releasable state." — Jez Humble & David Farley
Code must be merged to the main branch within one working day of inception. This forces:
- Granularity: Tasks must be decomposed into chunks small enough to be coded and reviewed in a day. This naturally reduces the variance (C_s) of service times.
- Continuous Integration: "CI" is not a server. It is a behavior. If you merge once a week - you are doing "Discontinuous Integration". We enforce true CI.
- Review Velocity: It creates pressure on the team to review code immediately. A 24-hour merge rule implies a 4-hour review SLA.
This is the only scientific answer to the question: How to deploy without breaking prod? Small batches. Frequent integration. Zero inventory. Large batches hide risk. Small batches expose it while it is manageable.
Constraint 3: The Definition of Done (The Deployment Clause)
We redefine "Done". In many teams - "Done" means "Coded". In ours - Done means Deployed.
Eric Ries, in The Lean Startup, emphasizes validated learning:
"The only way to win is to learn faster than anyone else... Validated learning comes from real customers using the product, not from internal milestones." — Eric Ries
A ticket is not closed when the Pull Request is merged. It is closed when the telemetry confirms the feature is active in production. This forces the engineer to take ownership of the deployment pipeline - the observability - and the release process. It aligns the engineer's incentive with the economic reality: until it is deployed - it is a liability (C_h) - not an asset.
Constraint 4: The Sync/Async Decoupling
To handle the "Synchronization Penalty" of distributed teams - we regulate communication channels.
- High-Bandwidth / Low-Latency: (Zoom/Huddle) Reserved for P0 incidents and complex architectural debates.
- Low-Bandwidth / High-Latency: (Ticket/Doc) Mandated for all task definitions and status updates.
We forbid "status meetings". Status is a state variable. It belongs in a database (the ticket system) - not in a verbal conversation. Meetings are for Decision Making only. This creates an asynchronous-first culture that is robust to timezone shifts.