Making Policies Explicit

Implicit rules create problems:

• People make different assumptions
• Conflicts arise over "how we do things"
• New team members don't know the unwritten rules
• Improvements are hard because the baseline isn't clear

Explicit policies are written, visible agreements about how work flows through your system.

They don't have to be complex. "We review PRs within 4 hours" is a policy. "Blocked items go to the top of the column" is a policy. "QA only starts if unit tests pass" is a policy.

Entry criteria: What must be true for work to enter a stage?

• "Ready for Dev: Acceptance criteria written, designs attached"
• "Ready for Review: All tests passing, no WIP commits"

Exit criteria (Definition of Done): What must be true to leave?

• "Development Done: Code reviewed, CI green, docs updated"

WIP limits: How many items can be in this stage?

• "Dev: Maximum 3 items in progress"

Handling policies: What happens in specific situations?

• "Blocked: Add blocker tag, discuss in standup, escalate after 24 hours"
• "Priority conflict: Senior dev decides, escalate to lead if needed"

Time policies: Expectations about timing?

• "Code reviews complete within 4 working hours"
• "QA starts within 1 day of ready"

Selection policies: How do we choose what to work on next?

• "FIFO within priority class"
• "Customer-facing bugs before internal issues"

Policies should be visible, not buried in documents nobody reads.

Options:

• On the board: Write policies above or beside each column
• Linked document: Keep a living policies doc, link from the board
• Tooltip/hover: Digital boards often support column descriptions
• Header card: First card in each column describes the policy

The test: Can a new team member understand the policies within 5 minutes of looking at the board?

Review cadence: Policies aren't static. Review them in retrospectives:

• Are we following this policy?
• Is this policy helping or hurting?
• What's missing?

Imposed policies don't stick. Collaborative policies do.

Process for creating policies:

1. Observe current practice: "How do we actually decide what to work on next?"
2. Surface disagreements: "It sounds like Alice pulls whatever's oldest, but Bob pulls whatever's smallest?"
3. Discuss trade-offs: "What are the pros and cons of each approach?"
4. Agree on policy: "Let's try FIFO for the next two weeks"
5. Make it visible: Write it on the board
6. Review and adapt: "How did FIFO work? Should we adjust?"

Key principle: Policies are experiments, not commandments. If a policy isn't helping, change it.

Over-documentation: 20 policies per column that nobody reads. Start with 2-3 essential policies per stage.

Under-enforcement: Policies exist but are routinely ignored. Either enforce them or delete them.

Rigid rules: "Never break WIP limit under any circumstances." Reality is messier. Allow for judgment while making the exception visible.

Missing escalation: What happens when policies conflict or break down? "If WIP limit is reached and urgent work arrives, escalate to team lead."

Stale policies: Rules from six months ago that no longer fit. Review policies regularly.

Individual policies: "Bob's work doesn't go through code review." Fairness matters. Policies should apply to work, not people.