Editor’s note: This article was reviewed and updated on 23 September 2024.
What are working agreements? How can we use them effectively as product managers?
A working agreement exists between team members to define how they’ll work together towards a common goal. Usually established as a formal document, working agreements guide teams to collaborate more effectively and productively while reducing conflict by covering topics like:
Although agile teams have the ability to function autonomously, they still need to work together to deliver quality projects. As a team member, you need to understand where you fit into the larger picture, regardless of your individual work style.
Agile teams often utilize T-shaped individuals who are knowledgeable in multiple domains. To foster a collaborative environment, these individuals must come together to create and agree on a way of working with each other. This is where a team working agreement comes into play.
In this article, you’ll learn what a team working agreement is and how having clear expectations about work can maximize collaboration among your team. We’ll also cover steps to create a team working agreement and provide a template you can use as a starting point for your team’s working agreement.
A team working agreement is a formal document that contains team roles, responsibilities, and communication methods, as well as a formal outline of the development and conflict management process.
Such an agreement enables open discussion and feedback mechanisms by creating a collaborative environment to nurture empathy and self-driven development.
Having a team working agreement allows for smoother collaboration between team members, as well as the following benefits:
Teams quickly evolve. According to the Tuckman model, teams go through five stages of development: forming, storming, norming, performing, and adjourning.
When a new team is first created, team members try to find a way of working with each other. They clash, normalize, become effective, and, eventually, adjourn. With time, team members change, new people join, and old team members move on, but the work continues and the cycle repeats. Because of this, you must clearly define responsibilities, expectations, and working methods.
Friction occurs when teams first form and becomes even worse during the growth phase. It can be difficult to work together effectively while attempting to deliver volume and maintaining speed.
Even when the team reaches maturity, it becomes time to expand, or for team members to move into new roles, introducing the possibility for conflict. Hence, you need a team working agreement to maintain stability of your team’s stage.
A team working agreement also helps with onboarding new team members. Often, during the onboarding phase, new members need clarification or support due to a lack of clarity in the team dynamics. A team working agreement serves as a key resource while onboarding and creates a shared understanding between old and new team members:
The team owns the working agreement, but it can be maintained and facilitated by the scrum master or product owner.
To create a team working agreement, a scrum master or a product owner can set up an exercise or a workshop to discuss and identify what should be included in the team working agreement based on need.
A team working agreement should always be open to suggestions. Define a way to submit proposals and a process to offer advice about the current document. It can either be by voting or discussion during team meetings.
In addition, you need to review the agreement periodically and iterate per the team’s current needs.
A team working agreement typically includes elements that are crucial to the team’s collaboration, communication, and overall functioning. While the specific content may vary depending on the team’s unique needs and preferences, there are common components that are often found in most working agreements.
In an agile team, many functions are intertwined with each other. For example, a typical product team includes roles like scrum master, business analyst, product owner, UX designer, data analyst, developer, system architect, quality assurance, system tester, etc. All of these roles depend on each other’s work.
It’s critical to outline roles and allocate individual names to each position. Sometimes people in the team may sit in multiple roles, which is completely fine as long as they acknowledge their jobs and can switch hats according to the context the team needs them at a given time. Similarly, multiple people can belong to one role, like a developer, so clarifying each member’s role brings ease and understanding.
In a self-driven team, the responsibilities must be more apparent since things may get lost in transition or fall between chairs.
Let’s look at an example of the responsibilities between a developer and a system tester, whose work often overlaps. A developer is responsible for developing the function and writing unit tests, while a system tester is responsible for writing automation test cases and conducting regression tests.
When a developer is done developing a story or a task, they are accountable for moving the ticket to the system test lane and assigning it to a designated tester. When the system tester finds a bug, they create a bug ticket under the task and transfer it to the respective developer again.
The bug ticket should have detailed information on how to recreate the bug, along with screenshots or a recording if possible. Suppose there is a clear description of the transition of tickets between the developer and tester. This will help to avoid confusion about the responsibilities, minimize conflicts, and foster collaboration by focusing on delivering quality.
One of the agile teams’ most significant challenges is keeping up with communication while maintaining pace. There are several scrum events identified to solve this very challenge. In the team working agreement the means and methods of communication should be clear.
For example, escalation or blockers should be raised in daily stand-ups, whereas you should reserve the solution discussion for follow-up meetings. Demo meetings showcase progress, whereas you can discuss the feedback and change requests in another forum. Describing all the platforms for discussion with a clear purpose of communication makes it easier to identify the best means to communicate.
Working in a team of passionate, driven individuals sometimes leads to a difference of opinion or approaches toward a solution. If someone cannot express those views constructively, or bring up something negatively, this can lead to frustration and irritation among team members.
Having a feedback mechanism is essential, but can be extremely sensitive if not handled appropriately. Both the giver and the receiver of feedback should be aware of the code of conduct as outlined in the team working agreement. Specifying feedback mechanisms in the team working agreement creates a safe space for the team members to speak their minds constructively.
For example, we specify appropriate forums to gather feedback and actions for general issues relating to the development, such as retrospectives. In case of any escalation due to unsatisfactory work conduct, contact the scrum master or team manager, escalate during one-to-one, or write an email as suitable.
This last one is infrequent, but helpful for conflict management. Describing a process for handling change requests in a team working agreement can be effective.
There are different reasons for different change requests, so there should be separate processes, decision orders, and communication methods for handling change requests:
Working agile requires you to accept change requests to learn and adapt iteratively. A problem occurs when the change requests are not conveyed to everyone. Therefore, it is essential to describe the process of managing all change requests. The best practice is to identify the following:
For example, a developer identifies an existing component that can be used. This entails changing the design a little, but will save two weeks of development required to create a new feature. The process could look like this:
You can set up a team working agreement by using these seven steps:
Here are some tips and best practices for creating a working agreement and using it effectively:
This template is designed to help you create a comprehensive and effective team working agreement. It covers the essential components described above, such as roles, communication expectations, and feedback mechanisms.
Based on the instructions outlined above, you can customize this template to suit your team’s unique needs and preferences:
Having clear responsibilities creates an efficient workplace that fosters happiness and innovation. A team working agreement mitigates frustration by allowing you to speak your mind and give feedback appropriately. It also helps prevent friction and overlaps of where one person’s obligations end and others begin.
Because this is an agreement created by the team for the team, it is also easy to implement and fall back on in times of conflict. A team working agreement is an excellent tool for creating a safe growing space and quickly transitioning the team without losing efficiency.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Cristina Fuser, VP, Product at Buzzfeed, talks about how being tech-led and data-led can be a strategic advantage.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
“Disagree and commit” is a management principle that encourages team members to voice their opinions during the decision-making process.
Learn more →
