A working agreement is often introduced as a one-time exercise: the team writes down some norms in an early workshop, the document gets stored somewhere, and it's rarely looked at again. Done that way, it's mostly ceremonial. Done well, it's a living reference that actually resolves the friction it's meant to prevent.
What a working agreement should actually cover
The useful working agreements go beyond generic statements ("we will communicate respectfully") toward specific, checkable commitments: what "done" means for a piece of work before it's considered complete, how quickly a team member is expected to respond to a direct message, what core hours the team is expected to be available for synchronous collaboration, how disagreements about technical approach get resolved when they don't converge naturally.
The generic version of a working agreement is largely useless precisely because it's unfalsifiable: nobody can point to a specific instance and say "that violated our agreement," because the agreement wasn't concrete enough to violate. The specific version can actually be referenced in the moment a disagreement occurs.
Build it with the team, not for the team
A working agreement written by a manager or Scrum Master and presented to the team for acceptance produces compliance at best. One genuinely built collaboratively, where team members articulate what actually bothers them about how the team currently works and what they'd prefer instead, produces something people are more likely to hold themselves and each other accountable to, because they recognize their own concerns in it.
Revisit it, don't just file it
Teams change composition, work changes in nature, and a working agreement written for a five-person co-located team doesn't automatically still fit once the team is nine people across three time zones. A brief, periodic check (does this still reflect how we actually want to work, is there recurring friction the current agreement doesn't address) keeps the document relevant instead of becoming a historical artifact from the team's early days.
Use it as a reference in the moment, not just in retrospectives
The real test of a working agreement is whether it gets invoked during an actual disagreement ("our agreement says we respond to blocking questions within two hours, and it's been six") rather than only being discussed abstractly during a retrospective weeks after the friction occurred. A working agreement that only ever gets discussed in the abstract isn't doing the job it's meant to do.
Teams sometimes treat writing a working agreement as the deliverable. The actual deliverable is a team that has a genuine, shared, specific-enough understanding of how it operates that disagreements about "how we're supposed to work" become rare, and resolvable, rather than a recurring low-grade source of friction.