Teamwork is such a fundamental part of the human experience that you would think that, after 200,000 years of human evolution, we would have it figured out. Unfortunately, the secret formula for building great agile teams still eludes us, and probably always will, because teams are made up of people—and people are complex and dynamic.
I've heard many complaints about underperformance, missed deadlines, or unmet goals from tech team leads and managers who have tried to apply a cookie-cutter approach to new agile teams. It simply doesn't work.
However, in my experience as an agile consultant, the most productive product development teams all have had one thing in common: consensus. They all felt included, heard, and respected in their own right, and could clearly make the connection between their individual purpose and the vision of the product or project.
On the flip side, I've seen teams that were hanging on by a thread and barely hitting their targets, if at all, because team members could not see how they fit in the big picture and just were not invested. Fortunately, there is a way to remedy this problem: the team working agreement.
Team working agreements are one simple practice you can use that will work wonders for building new teams as well as reforming existing ones. These agreements are a consolidation of guidelines that define how groups want to work together, and what they would ideally want, both in the working environment and from each other, to help foster a safe, open environment for productivity.
This social contract, created by team members, elicits a level of commitment, discipline, and accountability that positively affects team dynamics, and allows teams to successfully hit their intended targets. It helps teams create a positive, productive process suited to the team's needs and preferences.
These agreements have saved me a lot of grief, so I've shared a few tips below on how you can build one that works for your agile team. Also, I've included three examples of clauses I've used for my teams that you could use.
Here are a key things to consider when creating your own team working agreement.
Every team member must be actively involved
Team working agreements are designed to outline how team members will work together to create a positive, productive process. The only way for this to work is for each team member to add his or her two cents to the creation of these guidelines. All members' opinions matter, and inclusivity is the glue that holds the agreement together.
Your agreement must be team-specific
Every team has different nuances, and the contract should reflect that. Clarifying the needs and goals of your team makes it easier to create social contracts that have a positive impact. This also ensures that everyone is on the same page regarding what is expected at a given time during the execution of project work.
Address the uncomfortable topics
Working agreements provide the perfect opportunity to address touchy subjects such as how to handle conflicts and differences of opinion, as well as meeting schedules, underdelivery, and low engagement. These problems can't be swept under the rug with the hope of them disappearing.
Instead, as a way of being a proactive and self-organizing team, you should talk about these subjects and use the agreement as a plan of action to overcome them. If your team has already been working together for a while, you will have identified some of the main issues or concerns that your agreement needs to address.
Your contract should be flexible enough to accommodate changes to clauses or the introduction of new ones as the project progresses and as your team members learn more about each other.
It should be in your face, all the time
Your team working agreement must be made easily accessible and maintainable by all members of the team. It's easy to forget something you’ve only seen once in a meeting. Find creative ways to get the main items in your agreement consistently in your team's line of sight. One way I've done this is by creating a wall mural of sorts in the main workspace where the guidelines are displayed.
What to include in your agreement
Now that you've got the basics, here are examples of a few clauses you might include in your team working agreement. Some of these are specific to agile teams.
Time and place
Planning in agile is an ongoing activity that requires multiple± meetings. These meetings allow for visibility into how a project is progressing and account for the different levels of complexity required to successfully execute an iteration.
Meetings, however, can be a pain for everyone, especially when poorly planned. They feel like a waste of time that could have been invested elsewhere. What's particularly frustrating is that these tend to be impromptu meetings that disrupt everyone's day and that potentially affect team members' ability to complete their tickets in a given time frame.
Given this, it is necessary to build the planning cadence so that the team has a clear idea of what to expect and when. After experiencing several meeting mishaps with a team I worked with, we decided to create a “There Is a Time and Place for Everything” clause.
We decided that our various meetings would take place on x days at x times. It further extended to cementing where exactly these meetings would take place and who needed to be there. Now the team, as well as the wider organization, knows where we'll be and when, which causes few to no clashes.
This also allowed the team to develop a consistent rhythm for these meetings and helped them develop "muscle memory" to better plan for the upcoming timebox.
Majority rules
A crucial part of the agile process is backlog grooming and refinement, where one activity is to assign estimates to stories that have yet to receive one. This estimation is usually done through planning poker, where sizes are assigned based on the Fibonacci sequence.
Conflicts or differences in opinion related to what is to be done and how are typical side effects of this exercise. These differences can be healthy and, if carefully managed, can certainly trigger useful debates. It shows how people think differently, and allows for the expanding of team knowledge and insight.
The main issue with this is that it causes lengthy meetings. Teams generally continue pointing a story until a consensus is reached by all members. This can involve multiple rounds of planning poker, creating what seems like an endless cycle of pointing, asking questions, and repointing, all just to get everyone on the same page.
To do away with what can be an epic waste of time, we came up with a "majority rules" clause. How this works: When the team casts a vote on the effort required by a story, instead of going at it until all members are showing the exact same point, you use a majority vote. In other words, the point that has the highest number of persons choosing it will be the story point for that ticket.
In the event that there is a tie for a majority vote, ask the team if any members would like to adjust their vote based on supplemental information provided. This drastically reduces the time taken.
No distractions
There is nothing more frustrating, especially for a project manager, than having team members disengaged during an important meeting. While you're excited that you've gotten everyone to show up, you must face a new battle for the attention of the attendees who are glued to their devices or doing work that's unrelated to the meeting objectives.
Let's say you have 20 product backlog items to size, nine members on the team, and one hour to get through them all. You are taking the team through each PBI (product backlog item), ensuring that team members have all the relevant details, and answering any questions they might have.
Each time you get to the point where they size, it is an endless cycle of repetition; you either have to call on members and tell them that you are waiting on them to size, or they call out "pause" because they don’t understand what the PBI requires, going on to ask a question that was already answered.
They clearly weren’t paying attention. Because of this, one of two things ends up happening: Either the meeting runs long, or not all PBIs are sized in the timebox allotted. This reduces overall team productivity and can lead to missed deadlines, rushed work, or reallocation of time to get incomplete things done.
This was a regular occurrence on a team I led, and something had to be done. Cue our "no distractions" clause. This labels meetings as no-phone zones and states that laptops should be closed unless work being done directly relates to the meeting at hand.
It even goes as far as preventing external persons from interfering with attendees unless absolutely necessary. This helps ensure that attendees are there in mind as well as body, and promotes team engagement.
Focus on influencing team behaviors
These clauses aren't designed to dictate to the team how the work gets done, but should help emphasize team behaviors that will keep everyone accountable and productive.
The most important factor in developing a team working agreement is to identify the challenges your team is facing. Home in on the unique challenges to collaboration for your team, then focus your efforts on solving those specifically.
If you decide to use a team working agreement, the most important thing is to ensure your team is fully engaged in the entire process. Ensure that it addresses all the "itchy" or uncomfortable topics and that the agreement is placed somewhere that is easily accessible by the team.
Bear in mind that every team is different. The clauses that work for my team might not work for yours. So come up with your own style and figure out what works for your team.
Finally be creative in addressing your problems and have a bit of fun with the agreement. After all, it is a "social" contract.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
