methodatlas

Agile Operating practice

Working Agreements

Helps a team agree on observable rules for behaviour, communication, and escalation.

Working Agreements make implicit ways of working visible. The team gathers individual needs, writes observable rules, and decides how to adapt them later.

Core question
Which observable agreements help this team collaborate reliably and respectfully?
Participants
3-12
Time
10 minutes of preparation and about 60 minutes for the first agreement; then ongoing use and regular reviews.

The initial session becomes an ongoing practice through use and review.

Paper illustration for Working Agreements.
  1. Context

    Bound friction

    Make current collaboration, occasion, and observed friction visible.

  2. Perspectives

    Gather needs

    Record individual hours, communication, and feedback preferences separately.

  3. Rules

    Write observable norms

    Turn needs into clear “we” rules with trigger and expected behavior.

  4. Escalation

    Clarify interfaces

    Agree channels, response rules, decision ownership, and escalation path.

  5. Maintenance

    Plan review

    Set review date, change path, and response when an agreement cannot be kept.

Observe rules in use, keep, change, or remove them at review, and renegotiate early after team changes.

A good fit when

Use them for team formation, onboarding, reorganization, or recurring misunderstandings.

Ideal for

  • Team Kickoffs
  • Retrospectives
  • Distributed Teams

Not good for

  • Formal policy replacement
  • Conflicts without a willingness to align

Outputs

  • Reviewable agreement

    Living working-agreement document with observable rules, communication channels, escalation path, exceptions, owner, and review rhythm.

Working agreements

Fictional example

Fictional agreements for a distributed product team.

Hours and focus

When are we available, when do we protect focus, and which exceptions apply?

Core overlap 10:00–15:00; no internal meetings 09:00–11:00 except incidents.

Communication channels

Which channel serves which purpose and what response is expected?

Board for work status; chat for coordination within one working day; phone only for production incidents.

Feedback and decisions

How do we give feedback and where are decisions recorded?

Critical feedback directly first; decisions with context in the decision log.

Blockers and escalation

When and to whom do we escalate?

Mark a blocker after four working hours; escalate to Team Lead and Product after one working day.

Review

When and through what process do rules change?

Review in six weeks and additionally after onboarding or reorganisation.

The examples are starting points for joint negotiation.

Atlassian Working Agreements · original teaching example

First step

Collect current friction points and give every participant room for individual preferences.

Open the method guide

Deep dive

Purpose

When collaboration needs more than implicit expectations, it lays out shared ground rules openly. It creates reliability for conduct, availability, and decision paths.

How it works

It collects desired behavior and turns it into explicit agreements with a recognizable scope. This reduces room for interpretation and lets the team adjust behavior more easily later.

In detail

Working Agreements work because they translate implicit expectations into verifiable team agreements, reducing everyday friction. They only become effective when the wording is concrete enough to give orientation in tricky situations while still being jointly owned. Pure feel-good statements help little; robust agreements, by contrast, create a reference point for recalibration when collaboration falters.

Facilitation

Start with typical everyday work situations, such as handovers, reviews, or response times, so the rules stay grounded. The round becomes meaningful only once a general wish turns into a sentence against which behavior can actually be checked later. Close with clearly prioritized agreements, a visible place in daily team life, and a fixed occasion for review.

The method guide walks execution through 5 phases, timing, 5 pitfalls, and clear stop criteria.

Open method guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics
Artifact templates
Working Agreements: WorksheetPlan the initial agreement, use, and review with clear ownership.
markdown

working-agreements-checklist.md

Plan the initial agreement, use, and review with clear ownership.

Working Agreements: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Complete run Time: 10 minutes of preparation and about 60 minutes for the first agreement; then ongoing use and regular reviews.

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Shared document or board, individual work preferences, current friction examples, channel overview, and calendar.
  • Roles: Whole team · facilitator · team lead as participant, not sole author · rotating agreement owner
  • Advance information: Everyone notes working hours, focus time, feedback preferences, and current friction. The lead drafts at most communication and escalation questions, not finished rules.
  • Overall time needed: 10 minutes of preparation and about 60 minutes for the first agreement; then ongoing use and regular reviews.
  • Setup: Make existing rules visible, collect personal preferences silently first, and adopt only agreements the team can concretely try.

Prepare for the work steps

Context: Bound friction

  • Everyone notes working hours, focus time, feedback preferences, and current friction. The lead drafts at most communication and escalation questions, not finished rules.

Perspectives: Gather needs

  • Bounded friction situations

Rules: Write observable norms

  • Visible work preferences

Escalation: Clarify interfaces

  • Observable team rules

Maintenance: Plan review

  • Communication and escalation path

Working agreements

Hours and focus

When are we available, when do we protect focus, and which exceptions apply?

...

Communication channels

Which channel serves which purpose and what response is expected?

...

Feedback and decisions

How do we give feedback and where are decisions recorded?

...

Blockers and escalation

When and to whom do we escalate?

...

Review

When and through what process do rules change?

...

Collect personal preferences, then agree on a few observable rules for a trial period.

Atlassian Working Agreements · original teaching example

Context: Bound friction

Expected artifact: Bounded friction situations

Bounded friction situations

Entry:

...

  • Are friction points described as concrete situations without judging people?

Perspectives: Gather needs

Expected artifact: Visible work preferences

Visible work preferences

Entry:

...

  • Could everyone contribute work conditions and feedback preferences independently?

Rules: Write observable norms

Expected artifact: Observable team rules

Observable team rules

Entry:

...

  • Does each rule name a trigger and observable behaviour?

Escalation: Clarify interfaces

Expected artifact: Communication and escalation path

Communication and escalation path

Entry:

...

  • For urgent and non-urgent cases, are channel and escalation path clear?

Maintenance: Plan review

Expected artifact: Reviewable agreement

Reviewable agreement

Entry:

...

  • Can the team change rules that no longer work, and is the next review scheduled?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/working-agreements/run-sheet

Alternatives and neighbors

Fitting alternatives with decision guidance, followed by other related methods.

All methods
Constraints and origin
LowWorkshop45-90 min

Profile

Method form
Operating practice
Participants
3-12
Time
45-90 min
Maturity
Canonical
Origin
Praxisgemeinschaft
The Scrum Team inspects people, interactions, processes, tools, and the Definition of Done, then agrees on a few testable improvements.
Next up: Sprint Retrospective