A team disagrees about how quickly reviews should happen, which comments require changes, and when approval may be withheld. A Team Working Agreement turns those assumptions into shared, visible expectations for collaboration and code review. section 4.2.1 section 4.2.3
The agreement is a collaboratively owned document containing policies, standards, and social expectations that cannot be automatically enforced. Keep it accessible, editable, and explicit enough to guide authors, reviewers, and difficult conversations. section 4.1 section 4.6
Build the agreement around decisions the team can explain and apply:
- Set reasonable PR response times, follow-up expectations, review duration, and feedback-response norms. section 4.2.1 section 4.3.1
- Define review scope, approval guidelines, feedback cycles, disagreement handling, and what constitutes withholding or rejecting approval. section 4.2.3 section 4.3.1
- Record team coding standards and social expectations, including respectful behavior and keeping criticism focused on the code. section 4.3 section 4.4.7
- Automate repeatable checks such as formatting or scripts, reserving the agreement for decisions tooling cannot enforce. section 4.1 section 3.4.1
Changing an approval rule
A team requiring two approvers experiences emergency delays while key teammates are absent. It discusses the conflict between knowledge transfer and urgent fixes, then proposes a policy change through a TWA pull request. Everyone reviews the rationale and accepts, rejects, or compromises on the change. section 3.4.1 section 4.5.1
Treat the agreement as a living document: version-control it, make it the first item to pass through the team’s review process, and let anyone propose changes. Notify the team, discuss the proposal, and keep revisions manageable so outdated rules do not become ignored rules. section 4.5 section 4.5.1
