Team Working Agreements: How to Create Norms a Team Actually Keeps

Most teams have rules about how they work together. The trouble is that many of those rules are unwritten. One person expects replies within the hour, another checks messages twice a day. One manager treats meeting start times as firm, another as a suggestion. Nobody is doing anything wrong, but the friction adds up.

A working agreement is a short, written set of norms that a team creates for itself: how we communicate, how work enters the team, how we make decisions, and what we do when things go sideways. It is not an HR policy or a code of conduct handed down from above. It is the team's own answer to the question, "How do we want to work together?"

This guide explains where working agreements fit in agile ways of working, what to put in one, how to create it in a single session, and how to keep it alive so it doesn't end up as a forgotten document.

What a Working Agreement Is (and Isn't)

Agile frameworks treat explicit agreements as part of how a team runs. The Kanban Guide (May 2025) says that teams often need additional elements in their Definition of Workflow, "such as values, principles, and working agreements." The Official Guide to The Kanban Method from Kanban University goes further, describing explicit policies as agreements that should be "agreed to jointly between all parties involved," posted where people can see them, preferably right next to the team's board, and checked and adapted regularly. It also says: "At team level, a team agreement is a good way to introduce policies."

The same guide makes an important distinction: policies are not work instructions meant to relieve people of judgment. They should enable the team to organize itself. The guide lists the qualities good policies share: sparse, simple, well-defined, visible, always applied, and "readily changeable by those providing the service." That list is a useful test for any working agreement.

A working agreement also has limits. It cannot override company policy, employment law, or safety rules. If your organization already requires something, such as a records retention rule, the agreement can describe how the team follows it, not whether.

Why Norms Matter, and What Writing Them Down Can't Do

Clear norms reduce guesswork. When a new colleague joins, the Kanban University guide notes, they should quickly understand how work is organized through explicit policies, rather than learning by trial and error.

There is also a deeper reason. Amy Edmondson's 1999 study of 51 work teams in a manufacturing company, published in Administrative Science Quarterly, defined team psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking." She found it was associated with learning behavior, which in turn was linked to team performance.

But Edmondson is careful on one point that matters here. She writes that when tacit beliefs about interpersonal norms are made explicit, that "does not alter the essence of team psychological safety." In other words, writing "we welcome dissent" on a poster does not make people feel safe to disagree. What the team does when someone actually disagrees is what counts. A working agreement is a tool for making expectations visible, not a substitute for trust.

What to Cover

Good agreements focus on the friction your team actually experiences. Common topics include:

• Communication: which channel is for what (chat, email, the board), and reasonable response times for each.
• Meetings: start and end on time, agendas shared in advance, who decides whether a meeting is needed.
• Focus time: protected blocks where people aren't expected to respond.
• Intake: how new requests reach the team, for example, "All requests go on the board; we don't start work from hallway asks."
• Work in progress: how many items each person or the team takes on at once.
• Done: what "finished" means for common types of work.
• Decisions: who decides what, and how the team handles disagreement.
• Availability: core hours, time zones, and how to signal you're away.
• Escalation: when and how to raise a blocker.

You don't need all of these. Pick the five to ten that would make the biggest difference.

Creating One in a Single Session

Many teams can draft a first version in an hour or so. A simple format:

1. Set the purpose. Explain that the goal is a short list of behaviors the whole team commits to, and that it will be revised.
2. Gather pain points. Ask everyone to write, silently and individually, moments in the past month when working together felt harder than it should. Silent writing keeps the loudest voices from setting the agenda.
3. Group and choose. Cluster similar notes, then pick the clusters that matter most.
4. Draft specific behaviors. Turn each cluster into a "we" statement that someone could observe. "We respect each other's time" is a value; "We start meetings on time and end five minutes early" is a behavior.
5. Test for agreement. For each statement, ask whether everyone can live with it. If someone can't, talk about why and adjust.
6. Publish it. Put it where the team works: beside the board, at the top of the team channel, or in the shared workspace.

Imagine a hypothetical six-person marketing team that keeps missing launch dates because reviews stall. Their first agreement might include: "Reviewers respond to review requests within one working day, even if only to say when they'll get to it," and "Drafts go to review with the brief attached."

Making It Stick

Agreements fade when nobody looks at them. A few habits help:

• Review them in retrospectives. The Scrum Guide says that in the Sprint Retrospective the team inspects how the last Sprint went "with regards to individuals, interactions, processes, tools, and their Definition of Done." Your agreement fits naturally into that conversation. See our guide to running a team retrospective for formats.
• Let anyone point to them. Agreements work best when any team member, not only the manager, can say, "We agreed to put requests on the board. Can we add this one?"
• Revisit when the team changes. A new member, a new manager, or a move to hybrid work is a good reason to reopen the list.
• Retire what nobody needs. If an item hasn't been relevant for months, remove it. A shorter list is easier to keep.

Some teams also draw on shared values. The Scrum Guide names five: commitment, focus, openness, respect, and courage. Values like these can be a useful starting point for discussion, as long as the team translates them into concrete behaviors.

Common Pitfalls

• Too many rules. A two-page agreement is a policy manual. Aim for something that fits on one screen.
• Vague wording. "Communicate well" gives no guidance. Make each item observable.
• Imposed from the top. If a manager writes the agreement and asks for sign-off, it becomes a rule list rather than a shared commitment.
• Used as a weapon. Agreements are prompts for conversation, not evidence for performance reviews.
• Written once and forgotten. Without regular review, the document drifts away from how the team really works.

Key takeaways

• A working agreement is a short set of norms the team writes for itself, covering things like communication, intake, decisions and availability.
• Kanban guidance treats explicit, jointly agreed policies as part of a healthy workflow, posted near the board and changed by the people doing the work.
• Writing norms down does not by itself create psychological safety; how the team responds to speaking up matters more.
• Draft specific, observable "we" statements, test them for agreement, and keep the list short.
• Review the agreement in retrospectives and whenever the team changes.

Sources

• The Kanban Guide (May 2025), John Coleman and Daniel Vacanti
• Kanban University, The Official Guide to The Kanban Method
• Kanban University, The Kanban Method Glossary
• The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland
• Amy Edmondson, Psychological Safety and Learning Behavior in Work Teams, Administrative Science Quarterly (1999)
• Harvard Business School, Psychological Safety and Learning Behavior in Work Teams (publication record)