Team Agreements

Introduction.

Hi Everyone! Hope you have a good day.

And, as you can already see, we are going to talk about team agreements.
So, let me start with a question:

What is collaboration for you?

The first thing that comes to mind: it is a cooperative work of two or more people with the same goal.

It looks simple and straightforward. But is it so simple in the real world? We all know many stories about conflicts, misunderstandings, miscommunications, and, as the outcome, delayed or even failed projects. Let’s try to understand where those issues are coming from and what measures can reduce risks.

The most tricky word in the definition I have is ‘cooperative’ because it hides a lot of sense inside. Cooperation expects agreement on many areas, like goals (why people are working together), objectives (what exactly they want to reach), and methods (how they want to get them). Achieving alignment on all of them is quite a complicated task but still not the hardest one.

Proper discussions and understanding of each other’s points before starting your project can quickly and effectively solve the issue. So, why are we here and discussing this topic? The answer is Time.

Time can change people’s vision on any area of cooperation agreements they reached before. When goals are becoming obsolete — the entire project closes. New objectives will cause re-thinking of it. But changes in methods usually affect only a small fraction of people in the organization and can be resolved locally. In other words, changes in methods are usually not visible for all the people working around.

And this is how problems begin.

Let’s imagine a situation: two teams (5 people each) are working on the same project. Each of them is responsible for delivering their part of the result. And frequently, those results depend on the outcomes of another team’s work. Let’s also imagine that all the participants verbally aligned in all areas at the beginning of collaborative work. And then someone started a timer:

• Month #3: Team#1 found a more effective way to deliver their results and switched to it.
• Month #4: Two new experts (John and Mike) joined team#1. They received proper onboarding on how to do work and started their duty.
• Month #5: John was re-assigned to team#2 because management decided to have units of equal sizes.
• Month #6: Management received first complaints from John: “team#2 is not working effectively and doesn’t want to improve”. He tried to raise those topics during the team meetings but received many misunderstanding eyes staring at him instead of expected thankfulness.
• Month #6: During a one-on-one with the line manager Mike complained about though working environment. It was hard for him to do the job because he faced many communication issues, and some deliverables were waiting for days to be approved by the team.
• Month #7: After bad feedback provided by the teams, management fired John and Mike.
• Month #8: Company business was growing quite fast, and both teams requested new people. Hiring started.
• Month #11–12: Ten people joined the project and evenly spread across both teams to learn from them before creating two new teams.
• Month #13: Teams performance reduced by 40%. Based on the initial project members’ feedback, management assumed that it was related to the onboarding period and ignored the event.
• Month #15: Performance metrics showed the same values. Also, team members complained a lot about too many endless discussions happening around even simple topics (like how to validate finished pieces of work, deliver it to a customer, etc.)

Let’s stop here before this story becomes a novel and try to understand where everything went wrong.

1. John and Mike, as good as other new joiners, received terrible onboarding. No one explained to them all the team processes and current state of agreements. So they had to explore it by trying and failing. Things become worse when many new team members joined because their collective voice and vision started to have weight compared to the original team’s.
2. Managers fired people without proper understanding why teams did not accept all the new joiners.
3. After obtaining agreement on all the processes initially, teams forgot about aligning the methods they use to deliver results.
4. There was a lack of a single source of truth — a collaboration manifesto(project or team agreements) used to resolve conflicts and provide exhaustive information on how all the team processes should work together.

Keeping all those mistakes in mind, let’s develop our way to avoid them, buy building team agreements manifesto and mechanisms to maintain clarity, transparency, and adaptability around it.

Why do I need it?

If you have a team or colleagues working with you on the same project, here is the list of benefits you’ll have after the creation of documented team agreements:

• Reduce communication overhead. All the team members will use it as a reference to follow during day-to-day work.
• Effective and fast onboarding. No need to keep in mind all the practices and methods. Just keep it up to date, and your new allies will have much less stress trying to understand how everything works.
• Transparency. Other teams and managers will see the way you work and will be able to predict some results based on that information.

Action plan.

Let’s start with what we already have. It doesn’t matter if you are creating a new team or working in one for a couple of years. Everything begins with the creation of a document with the title “Team Agreements.”

Did it? Then share it with your team. Yes, it is blank and contains nothing, but you need to fill it together.

The next step is a bit more complicated. Ask team members to write in the document all the best practices they see already used in the current team and methods they think will be useful to adopt — one statement per line.

Examples (for an Agile team) can be the following:

• Have two weeks spring.
• Grooming (also known as backlog refinement) once per week.
• Have 15% buffer in each sprint for unpredicted issues and high-priority bugs.
• Have no more than two spring goals
• Limit amount of tickets in review state to 5 (WIP limit).
• Hire new members after face-to-face meetings with team members.
• Split tickets greater than X story points.
• Include developers in communication with customers
• etc.

Afterward, spend some time filtering and aggregating those ideas in small groups. Find ideas that are not concrete enough and ask its author to clarify them. Also, put together items that correlate or conflict with each other.

Example:

• A group of conflicting statements:

1. John wrote: let’s switch to Kanban.

2. Mike: Use Scrum with 4-week sprints.

• A group of correlated ideas (similar ideas with different warding):

1. Do automated quality assurance before releasing changes.

2. Improve release quality by using automated tools.

• Not concrete idea:

1. “Improve team velocity” is useless because it doesn’t hint at how we want to improve. “Improve team velocity by reducing the average size of the ticket” looks much more concrete.

After ideas are grouped, the team needs to discuss them. Create a meeting for all members with duration calculated by the formula:

Time = <number_of_groups> * 5 mins + 20 mins.

During this meeting, you will read each group of statements, ask authors shortly explain it to the entire team, discuss it and, finally, decide if it is good to be adopted or not. It is crucial to have a common understanding of each statement by all the team members and a collective decision to embrace it. We recommend taking a final decision by voting, where the team needs to be inclined to accept the change almost entirely. Don’t worry if the team will reject some of the good ideas. It is not ready for them yet, and they will come back later.

Meeting plan:

• Short introduction (5–10 mins). Describe the goal of the event and the way to work.
• Go through each group of statements, following the timing:

1. Read it for every one (1 min.)
2. Ask authors to explain their thoughts and answer questions from other members (3 mins).
3. Vote for a specific statement in the group (1 min.) If rejected — erase it from the document. If accepted — keep it as is or rephrase it to be more understandable for all the members.

• Explain the ways how those agreements can be used and modified in the future. (5–10 mins).

How to maintain?

As mentioned before, methods are not static and immutable. New best practices release quite frequently in our days. And we need to ensure that our Team agreements are flexible enough to stay on the wave.

Luckily, the team will do it by itself, but we need to ensure that members can spend some time reflecting on them.

The best way to make it happen — have a small meeting. It should not be a frequent one or even can be on-demand. But it should be scheduled in everyone’s calendar once per month or bi-weekly and be a notification that this is a moment when the team can become better, try new practices, or get rid of the obsolete ones. For Scrum teams, a retrospective meeting will be the best feet for that.

Here is an example of how such kind of meetings could go:

• Discuss ideas adopted by the team recently. Are they working? Do they need to be adjusted or even removed from the list?
• Discuss new propositions and ways how to make them work in the team.
• Update Team Agreements document if needed.

Conclusion.

That’s it. Simple, maintainable, and adaptable. Don’t forget to keep up to date your team’s agreements, share them with new joiners and managers, and enjoy the transparency they will bring to your work processes.

Many thanks for reading and staying with us.
We are working towards improving the format and the way to deliver new practices to you and your work.
Please support us via:
Patreon — where you can get free downloadables for all the patrons and influence the following topics;
PayPal — to say thank you and ensure faster publication of new articles.
Follow us on LinkedIn, Twitter, Instagram, Medium to stay in touch.
And stay Curious.