Engineering teams that work well together rarely do so by accident. Behind most high-performing teams is a set of explicit shared commitments about how they communicate, make decisions, handle disagreements, and hold each other accountable. 

These commitments are called working agreements, and in 2026, with hybrid teams, distributed time zones, and AI agents now part of the standard engineering workflow, they have never mattered more.

This guide covers what working agreements are, why they matter, what to include in them, how to create one that actually sticks, and what a practical template looks like for a modern agile team.

What Are Working Agreements?

A working agreement is a living document created and owned by the team that defines how its members collaborate, communicate, and hold each other accountable. It is not a set of corporate rules handed down from management. It is a shared commitment that the team writes together, revisits regularly, and updates as their context changes.

The key word is shared. A working agreement that was written by one person and emailed to the rest of the team is not a working agreement, it is a policy document. The distinction matters because buy-in comes from participation. Teams that write their own agreements are far more likely to follow them than teams that receive them.

Working agreements typically cover communication norms, meeting expectations, workflow standards like definitions of done and ready, quality requirements, AI and tooling governance, and how conflicts get resolved. In 2026, AI governance has become one of the most important sections a team can define, given how quickly tooling has changed and how significant the quality and security implications of AI-generated code can be.

Why Do You Need Working Agreements?

The default in most teams is that norms emerge informally over time. Some team members develop assumptions about review turnaround times, others develop different assumptions, and conflict arises not because anyone is acting in bad faith but because the expectations were never made explicit.

Working agreements address this directly. They replace assumption-based conflict with explicit shared standards. When a working agreement says that pull requests should be reviewed within 24 hours during business days, there is no ambiguity about whether a 48-hour wait is acceptable. When it says that all AI-generated code must be flagged in pull requests and reviewed for logic and security, there is no ambiguity about whether that applies to boilerplate.

The benefits compound over time. New team members onboard faster because the working agreement explains how the team operates rather than leaving them to decode it through observation. Retrospectives become more productive because there is a document to evaluate actual practice against. And distributed or hybrid teams, where informal norm-setting through proximity is not possible, get the structure they need to coordinate effectively across time zones.

What Should You Include in Working Agreements?

The right content depends on the team, but most effective working agreements in 2026 cover the following areas.

Communication and Collaboration

Define where different types of communication happen and at what speed. Which channels are for urgent matters and which are for async updates? What are the expectations during deep work blocks? When is a Slack message appropriate versus a Jira comment versus a video call?

A useful approach is to establish channel etiquette that routes project decisions through the issue tracker, where they create a searchable audit trail, while reserving Slack and Teams for time-sensitive coordination. This prevents important decisions from being buried in chat history that no one can find three months later.

Response time expectations are worth making explicit, particularly for teams across multiple time zones. A 3 to 4 hour core overlap window where everyone is available for synchronous collaboration, with async defaults outside that window, is a pattern that many distributed teams have found workable.

AI and Tooling Governance

This section has become essential in 2026. Most engineering teams are now using multiple AI coding tools, and the absence of explicit governance creates real security, quality, and legal risk.

The agreement should state which AI tools are approved for use, whether that is Cursor, GitHub Copilot, Claude Code, or others, and which are not. It should explicitly prohibit sharing customer data, credentials, or proprietary business logic with public AI models. It should define how AI-generated code gets handled in the review process: whether it needs to be flagged in pull requests, what the review standard is for AI output versus human-authored code, and who is responsible for verifying logic and security.

As AI agents take on more autonomous tasks, the governance section should also address how agent-initiated changes get tracked and reviewed before merging into production branches.

Workflow and Quality Standards

The Definition of Ready and Definition of Done are the most widely used working agreement artifacts in agile teams, and they belong here.

The Definition of Ready defines what a story or ticket needs to contain before it is eligible to enter a sprint: acceptance criteria, technical design, dependency identification, and whatever else the team has found necessary to avoid mid-sprint discovery of blocking ambiguity.

The Definition of Done defines what completion means: code merged, tests passing, documentation updated, peer review complete, and any other quality gates the team has agreed are non-negotiable. Making this explicit eliminates the common situation where one engineer considers something done and another considers it still in progress.

Pull request size limits are worth including here. Keeping pull requests small, a common guidance is under 200 lines, makes reviews faster, reduces merge conflicts, and decreases the blast radius of any individual change.

Hybrid and Time Zone Norms

For distributed teams, this section defines the structural commitments that make remote collaboration sustainable. Core hours establish when all team members are online for synchronous work. Meeting hygiene standards ensure that no meeting happens without an agenda and a designated note-taker. Practices like no-meeting Wednesdays protect deep work time that would otherwise be fragmented by calendar overhead.

For teams across multiple time zones, explicit guidance on asynchronous-first defaults is critical. The agreement should make clear that being in a different time zone is not a performance disadvantage, and that the team's measurement of contribution is based on outcomes rather than online presence.

Conflict Resolution

Disagreements about technical direction are inevitable and healthy. The working agreement should define how they get resolved before one arises, not during. A common pattern is to time-box technical discussions to 15 minutes, then designate a decision-maker, often the tech lead, who makes the call and the team commits to it. Leaving the decision-making process undefined leads to unresolved debates that slow delivery and create resentment.

How to Create a Working Agreement

Schedule a Dedicated Session

Working agreements cannot be created as an aside during a regular sprint ceremony. Block 60 to 90 minutes specifically for the exercise, ideally at the start of a new team formation, after a significant team change, or at the beginning of a new product cycle.

Set the Stage

Open the session by explaining what a working agreement is and is not. It is a shared commitment the team writes together, not a rules document from management. The tone should be collaborative and forward-looking: what would make this team excellent to work on?

Gather Input from Everyone

The most common failure mode in working agreement creation is letting one or two voices dominate while others stay silent. Use structured input gathering: have each person write their thoughts independently before the group discusses, then surface all inputs before filtering. This prevents the loudest opinion from becoming the default before everyone has had a chance to contribute.

Remote teams should use collaborative digital tools that allow simultaneous input so that no one is waiting for a turn to speak.

Prioritize and Refine

A working agreement with 40 items is not a working agreement, it is a manifesto that no one will read. After gathering input, prioritize: which norms have the highest impact on how this team works? Which are genuinely new agreements versus things the team already does? Start with five to ten items that address the most important or most contested aspects of the team's collaboration, and add more over time.

Plan for Regular Review

A working agreement written once and never revisited becomes a historical document. Build review into the team's regular cadence by including a brief working agreement check-in during retrospectives every two to three sprints. Ask whether the agreements are still accurate, whether any are being consistently violated in ways that suggest they need to change, and whether new situations have arisen that the agreement does not cover.

5 Best Practices for Team Working Agreements

1. Keep It Simple to Start With

The temptation when creating a working agreement is to try to cover everything. Resist it. A short document that everyone understands and actually follows is more valuable than a comprehensive one that sits unread. Start with the most important five to ten agreements and expand from there.

2. Document Your Working Agreements in One Place

The agreement should live in a single, accessible location that every team member knows about. Notion, Confluence, and GitHub Wiki are all common choices. The location matters less than the consistency: if some people reference one version and others reference another, the agreement has already fragmented.

3. Keep Your Working Agreements in Sync with Real Life

If the team consistently violates a particular agreement without anyone raising it, that is usually a signal that the agreement does not reflect how the team actually works or wants to work. Update the agreement to reflect reality, then decide whether the new norm is acceptable or whether it signals a problem that needs addressing.

4. Make It Easy to Propose Changes

The working agreement should have a clear process for suggesting updates. Anyone on the team should be able to propose a change, and the change should be reviewed at the next retrospective rather than requiring a special session. This keeps the document alive rather than frozen.

5. Go Through the Working Agreements with New Team Members

The working agreement is one of the most useful onboarding documents a team can have. It explains how decisions get made, where communication happens, what the quality standards are, and how conflicts get resolved, all of the implicit knowledge that new hires otherwise spend months trying to decode through observation. Make reviewing the working agreement a standard part of the onboarding process.

How to Make Working Agreements Stick

Automate All the Agreements You Can

Any working agreement that can be enforced through tooling should be. If the agreement says pull requests must include a test, configure the CI pipeline to require it. If the agreement says AI-generated code must be flagged, add a PR template that includes a required checkbox. Moving agreements from manual compliance to automated enforcement removes the social friction of reminding teammates and ensures consistency regardless of who is reviewing.

Use Code Reviews and Retrospectives

Code review is one of the most natural places for working agreement norms to be reinforced. When a pull request violates the agreed PR size limit or lacks the required documentation, the review is the moment to surface it, not as a personal critique but as a reference back to the shared commitment.

Retrospectives serve the same function at the team level: a regular structured moment to evaluate whether the team is living its agreements and whether those agreements still serve it well.

How Pensero Connects to Working Agreements

Working agreements define how a team intends to work. Pensero shows how it actually works, and whether the gap between intent and reality is widening or closing.

Pensero is an empowerment tool for engineering performance that brings together real signals from GitHub, Jira, and the tools your team already uses to uncover how work moves, where it gets blocked, and how development practices and AI usage translate into real business impact. 

For teams that have agreed on PR review turnaround times, delivery cadence, or AI adoption norms, Pensero provides the objective signal that shows whether those agreements are translating into performance.

Pensero Calibrate lets leaders compare any two cohorts on 11 complexity-weighted metrics with company average and industry median as built-in reference lines. For teams with working agreements around AI governance, this means comparing AI-adopter and non-adopter cohorts on delivery, quality, and cycle time with data rather than intuition. For distributed teams with agreements about remote and onsite norms, it means comparing locations on the same complexity-weighted framework with the industry median as context.

Pensero Benchmark ranks the organization against real anonymized production data from comparable engineering organizations. If a team's working agreements are well-designed and consistently followed, it shows up in the benchmark. If performance is lagging despite agreed norms, the benchmark surfaces where the gap is.

Working Agreement Template for Agile Teams

The following template can be adapted for any agile engineering team. Copy it into your team's documentation tool, fill in the specifics, and schedule a session to review and complete it together.

Team Name: [Insert team name]

Last Updated: [Insert date]

Next Review: [Insert date, typically 2-3 sprints from last review]

Our Values

[Example: We value transparency over perfection, progress over busyness, and direct feedback over avoidance.]

Communication

Primary channel: [e.g., Slack #team-name for async updates]

Urgent matters: [e.g., Direct message or call for P0 issues only]

Decision log: [e.g., All decisions recorded in the relevant Jira ticket or Notion page]

Deep work hours: [e.g., 1pm to 4pm daily — no non-urgent pings]

Core overlap hours for synchronous collaboration: [e.g., 10am to 1pm CET / 4am to 7am EST]

Meetings

Daily stand-up: [Time and link] — Focus on blockers, not status updates

Sprint retrospective: [Cadence and link]

Meeting hygiene standard: Every meeting has an agenda posted 24 hours in advance and a designated note-taker

No-meeting block: [e.g., Wednesdays are protected for deep work]

AI and Tooling Governance

Approved AI tools: [List approved tools, e.g., GitHub Copilot, Cursor, Claude Code]

Data policy: No customer data, credentials, or proprietary logic to be shared with public AI models under any circumstances

Review standard: All AI-generated code must be flagged in pull requests and reviewed for logic correctness and security before merge

Agent output: Autonomous agent changes follow the same review process as human-authored changes

Workflow and Quality

Definition of Ready: Stories must have clear acceptance criteria, technical design notes, and identified dependencies before entering the sprint

Definition of Done: Code merged to main, tests passing, documentation updated, and peer review completed

PR size guideline: Pull requests should stay under 200 lines of change where possible to enable thorough review

PR turnaround expectation: First review within [e.g., 24 hours] on business days

Conflict Resolution

When the team disagrees on a technical direction: time-box the discussion to 15 minutes, then [Tech Lead or designated decision-maker] makes the call. The team commits to the decision regardless of individual preference, and the rationale is documented in the relevant ticket.

Working Agreement Review Process

This document is reviewed during every third retrospective. Any team member can propose a change at any time by posting it to [designated channel or document comment thread]. Changes are discussed and ratified during the next retrospective.

Frequently Asked Questions

What is an agile working agreement?

An agile working agreement is a document created and owned by the team that defines how its members collaborate, communicate, make decisions, and hold each other accountable. Unlike corporate policies, working agreements are written by the team itself and updated regularly to reflect how the team actually works.

How often should you review working agreements?

Most teams review their working agreements every two to three sprints during retrospectives. A lighter touch is to ask at the end of each retrospective whether any agreements need updating, and schedule a deeper review every quarter or after significant team changes.

Who should create the working agreement?

The entire team should participate in creating the working agreement. Agreements created by one person and handed to the rest of the team lack the buy-in that makes them effective. The creation process itself, gathering input from everyone and prioritizing together, is part of what makes the document meaningful.

What is the difference between a working agreement and a Definition of Done?

A working agreement is a broader document covering all aspects of team collaboration including communication, meetings, conflict resolution, and quality standards. The Definition of Done is one component that typically lives within it, defining what conditions must be met for work to be considered complete.

How do working agreements apply to distributed and remote teams?

Working agreements are especially important for distributed teams because the informal norm-setting that happens through physical proximity is not available. Explicit commitments about core overlap hours, async-first defaults, meeting hygiene, and outcome-based measurement replace the informal coordination that co-located teams take for granted.

How do you handle AI governance in a working agreement?

The AI governance section should specify which tools are approved, what data can and cannot be shared with those tools, how AI-generated code is flagged and reviewed in pull requests, and how autonomous agent output is handled before it reaches production. Given how rapidly AI tooling changes, this section should be reviewed more frequently than the rest of the document.

How can you tell if your working agreements are actually working?

Retrospectives are the primary mechanism for evaluating whether agreements are being followed. Tooling can automate enforcement for agreements that have technical implementations. And for engineering performance outcomes, platforms like Pensero provide objective data on whether delivery patterns, quality signals, and AI adoption are trending in the direction the team's agreements are designed to support.