Working Agreements

The concept of teams establishing their own norms is not new, but it gained significant prominence within Agile frameworks, particularly Scrum, where self-organizing teams are a core tenet. Early Agile practitioners recognized that while frameworks provide structure, the nuances of team dynamics, communication styles, and conflict resolution needed to be addressed directly by the team members. The emphasis on continuous improvement (Kaizen) and regular introspection, often facilitated through events like the Sprint Retrospective, naturally led to teams identifying areas where explicit agreements could enhance their performance and well-being.

The primary purpose of Working Agreements is to create clarity and reduce ambiguity within a team. By explicitly stating how they will work together, teams can proactively address potential misunderstandings, minimize friction, and build a foundation of trust. This clarity extends to various aspects of team life, from how meetings are conducted and decisions are made, to how feedback is given and conflicts are resolved. They help to establish a predictable and safe environment where team members feel comfortable expressing ideas, challenging assumptions, and taking risks without fear of negative repercussions, thereby fostering psychological safety.

Working Agreements are important because they directly impact team effectiveness and morale. Without them, unspoken assumptions can lead to frustration, inefficiency, and interpersonal conflict. For instance, one team member might assume prompt responses to messages, while another prioritizes deep work without interruption. An agreement on communication channels and response times can bridge this gap. They empower teams to take ownership of their processes and culture, reinforcing the Agile principle of self-organization. When a team collectively decides on its operating norms, there is a higher likelihood of adherence and a stronger sense of shared responsibility.

Working Agreements fit within the wider Agile knowledge graph as a practical application of several core principles. They are closely related to Team Charters, which often include Working Agreements as a component, defining the team's purpose, boundaries, and operating model. They complement the Definition of Done by addressing the "how we work" rather than just the "what we deliver." While the Definition of Done focuses on the quality criteria for increments, Working Agreements focus on the behavioral criteria for team collaboration. They are frequently created, reviewed, and updated during Sprint Retrospectives, serving as actionable outcomes for continuous improvement. They also support Visual Management and Information Radiators by often being displayed prominently, making team norms transparent and accessible to everyone.

Workflow for Creating and Maintaining Working Agreements:

1. Initiation: Working Agreements are often initiated when a new team forms, or an existing team identifies a need for improved collaboration, perhaps during a Sprint Retrospective. A facilitator (e.g., Scrum Master, Team Lead) typically guides the process.
2. Brainstorming & Discussion: The team collectively brainstorms areas where agreements would be beneficial. This can cover a wide range of topics, such as:
   • Communication: How and when to communicate (e.g., "Respond to Slack messages within 2 hours during working hours," "Use email for formal documentation").
   • Meetings: Norms for specific events (e.g., "Start Daily Scrum on time," "Respect Timeboxing," "No laptops during Sprint Review").
   • Decision Making: How decisions are made (e.g., "Strive for consensus, default to Product Owner for product decisions").
   • Conflict Resolution: Steps to take when disagreements arise (e.g., "Address issues directly with the person involved first," "Escalate to Scrum Master if unresolved").
   • Feedback: How feedback is given and received (e.g., "Provide constructive feedback directly and privately," "Assume positive intent").
   • Focus & Interruptions: How to manage distractions (e.g., "Use 'do not disturb' status for focused work," "Knock before interrupting someone with headphones").
   • Code Quality/Engineering Practices: While some aspects might be covered by Definition of Done, others might be behavioral (e.g., "Always conduct peer code reviews," "Leave the codebase cleaner than you found it").
3. Drafting & Refinement: The brainstormed ideas are refined into clear, concise, and actionable statements. The language should be positive and focus on desired behaviors. For example, instead of "Don't be late," it would be "Arrive on time for all meetings."
4. Consensus & Commitment: The team discusses each proposed agreement until a consensus is reached. This doesn't necessarily mean everyone loves every agreement, but everyone can commit to upholding it. Techniques like Fist-to-Five or Roman Voting can be used to gauge consensus.
5. Visibility: Once agreed upon, the Working Agreements should be made highly visible. This could be a physical poster on a wall (an Information Radiator), a dedicated page on a team wiki, or a digital document accessible to all. This ensures they are always present and easily referenced.
6. Review & Adaptation: Working Agreements are not static. They should be regularly reviewed and adapted, typically during Sprint Retrospectives or other team reflection events. As the team evolves, new challenges arise, or existing agreements prove ineffective, they can be modified, added, or removed. This continuous improvement cycle (Kaizen) ensures their relevance and effectiveness.
7. Accountability: Team members are expected to hold themselves and each other accountable to the agreements. This requires courage and a safe environment for peer-to-peer feedback. When an agreement is broken, it's an opportunity for the team to inspect and adapt, either by reinforcing the agreement or by modifying it if it's no longer serving the team.

The process emphasizes team ownership and self-management. The facilitator's role is to guide the discussion, ensure everyone's voice is heard, and help the team arrive at agreements they can all commit to, rather than dictating the rules.

Benefits

• Improved Communication: By explicitly defining communication channels, response times, and meeting etiquette, teams can reduce misunderstandings and ensure information flows effectively.
• Reduced Conflict: Clear agreements on how to address disagreements, give feedback, and make decisions can prevent minor issues from escalating into major conflicts.
• Enhanced Team Performance: A shared understanding of norms leads to greater predictability, less wasted effort on navigating interpersonal dynamics, and more focus on delivering value.
• Increased Accountability: When agreements are co-created, team members feel a stronger sense of ownership and are more likely to hold themselves and each other accountable.
• Fosters Psychological Safety: Explicit rules of engagement create a safer environment where team members feel comfortable being vulnerable, experimenting, and challenging ideas constructively.
• Supports Onboarding: New team members can quickly understand the team's culture and expectations by reviewing the existing Working Agreements, accelerating their integration.

Limitations

• Require Active Maintenance: Working Agreements are not "set it and forget it." They need regular review and adaptation, which requires dedicated time and effort from the team.
• Can Become Stale: If not regularly revisited, agreements can become outdated or irrelevant as the team evolves, leading to them being ignored and losing their value.
• Not a Substitute for Leadership: While empowering, Working Agreements don't replace the need for effective leadership in guiding the team, resolving intractable issues, or setting strategic direction.
• Risk of Being Ignored: If agreements are not truly owned by the team, or if there's a lack of commitment, they can become mere words on a wall, failing to influence actual behavior.
• Can Be Overly Prescriptive: If too many agreements are made, or if they are too detailed, they can stifle creativity and adaptability, turning into bureaucratic overhead rather than helpful guidelines.

Common Mistakes

• Imposing Agreements: Agreements dictated by a manager or facilitator, rather than co-created by the team, will lack ownership and commitment.
• Making Too Many Agreements: Overwhelming the team with a long list of rules can make them difficult to remember and follow. Focus on the most impactful areas.
• Not Reviewing or Adapting: Failing to revisit agreements regularly means they won't evolve with the team, becoming irrelevant or even detrimental.
• Lack of Visibility: If agreements are hidden away in a document, they won't serve as a constant reminder of desired behaviors. Make them prominent.
• Ignoring Breaches: When an agreement is broken, and the team doesn't address it (even gently), it signals that the agreements are not important, eroding their value.
• Vague or Ambiguous Language: Agreements like "Be respectful" are too broad. They need to be specific and actionable, e.g., "Listen actively without interrupting."

Real-world Examples

Consider a software development team working on a complex product:

• Daily Scrum: "Everyone arrives on time for the Daily Scrum. If you're late, you bring coffee for the team." (A lighthearted way to reinforce punctuality).
• Code Reviews: "All pull requests must have at least two approvals before merging. Reviewers must provide constructive feedback within 4 hours during working hours."
• Interruptions: "For urgent matters, tap on the shoulder. For non-urgent questions, use Slack and expect a response within 2 hours. For deep work, use 'Do Not Disturb' status."
• Conflict Resolution: "If you have an issue with a team member, speak to them directly first. If unresolved, involve the Scrum Master."
• Feedback: "When giving feedback, focus on the behavior, not the person. When receiving feedback, listen actively and ask clarifying questions."
• Definition of Done: "Code is peer-reviewed, passes all automated tests, has updated documentation, and is deployed to staging." (This is a specific type of working agreement).

Best Practices

• Team-Owned and Co-Created: Ensure every team member participates in their creation and agrees to them.
• Keep Them Concise and Actionable: Focus on a few key behaviors that will have the most impact. Use clear, positive language.
• Make Them Visible: Display them prominently (e.g., on a physical board, digital wiki, or Information Radiator) so they serve as a constant reminder.
• Regularly Review and Adapt: Integrate their review into Sprint Retrospectives or other regular team meetings.
• Lead by Example: Team leaders and senior members should consistently model adherence to the agreements.
• Address Breaches Constructively: When an agreement is broken, use it as a learning opportunity for the team to discuss why it happened and how to prevent it in the future, rather than as a punitive measure.
• Focus on Behaviors, Not Personalities: Agreements should target specific actions and interactions, not individual traits.