Project-specific Team Working Agreements

The internet is full of resources for creating Team Working Agreements. There are thorough articles from Scrum Alliance, Atlassian, and Microsoft to get your group started. But what if you have a well-established team confronting a new challenge? What if the Team Working Agreement that's served you well so far might not work for a different kind of project? Then it might be time to create a Project-specific Team Working Agreement to meet the needs of your new situation. This article introduces this kind of agreement, along with details of why and how to create one.

During the first half of the year, our team at Pluralsight had been operating within an eight week cycle– a modified version of Basecamp’s six week cycle. But in order to better fulfill business and customer needs, our group and others were switching to two week sprints for the second half of the year. Also during the first half, our team had been juggling three different initiatives, but in the latter half we were focusing our efforts on a single one. In order to meet our forecasted end date, this singular focus would require full-team utilization and corresponding parallelization. Just before the initiative kicked off, we revisited our Team Working Agreement.

Our existing agreement was sound. For communication, it contained statements like “be proactive” and “err on the side of overcommunicating”. On the technical side, we knew that “we push our own changes to production” and “PR reviews should remain a priority”. Still, it felt like something was missing. This time was different. How would we adjust our iterative abilities to two weeks instead of eight? How could we prevent the proverbial stepping on toes with all of the parallel work? Special consideration was needed, and thus the Project-specific Team Working Agreement was born.

Utilizing Figma’s outstanding TAT (Team Agreement Template), we set out to create our Project-specific Team Working Agreement. How would this exercise be different from the last time we created an agreement? It turned out that the answer was right in front of us. Up to this point in our project planning, we had been asking questions that poked holes in our existing document. We simply needed to modify the questions, and generate new ones, so that they fit in Figma’s TAT. What follows are the parts of our exercise, with example content included in each.

An important first step of many team activities, and especially ones in which you will be authoring a process, is a “getting to know you” icebreaker. This part 1) helps our team learn a little more about each other, 2) reveals how we are different, and therefore 3) sets the stage for why our answers might get in each other’s ways in future parts.

Part 1 of Figma’s TAT includes such a section. We chose questions that would set the mood for a project we felt differed from our previous ones. As a first example, we believed that the new project would require significantly different guiderails than previous ones, though we didn’t know at this stage if there would be more or less. We needed a “getting to know you” question related to rules, so we asked team members to describe themselves as rule-followers or risk-takers.

As a second example, we felt the new project, since it would require some work in parallel, would have different requirements for multitasking and context-switching. So we asked team members if they prefer multitasking or working with no distractions. With the mood set and the icebreaker out of the way, we continued with part 2.

Part 2 of Figma’s TAT involves a series of statements, with each one having an agreement scale on which team members would vote. If answers were clustered together, it meant we had a consensus. If answers were spread apart, discussion was required to come to a resolution. In the end, we would identify the statements that were most aligned with our views and those we felt strongly about.

Again, we wanted to choose statements related to how the new project would differ from previous ones.

Our sentences tended to be somewhat polarizing. I wanted team members to feel compelled to make a choice on the alignment scale. The following are some of the differences that were hypothesized:

1. The new project would be more subject to scope creep.
2. The new project risked having unnecessary complexity.
3. Developers would need to mob program in order meet the forecasted completion date.

Below are some of the resulting statements.

Part 3 is the ideation phase. The team took what we’d learned from the two previous sections to brainstorm working agreement statements. We agreed that everything was on the table, and that they should not limit themselves to our original hypothesized differences. The team quickly jotted down working agreement-like sentences that had an air of gravitas, were pertinent to our new project, and were not contained in our previous working agreement. The following are sample statements.

The time had come to put pencil to paper– to select those statements that would be included in our final working agreement and determine how they would be structured. The team spent some time combining similar statements. Some wordsmithing was also done during this part. Then it was time to vote, and I asked team members to put a star next to the statements they felt were essential.

We also organized the statements. I’m not sure if there’s a hard and fast rule here, but we chose Pre-coding, Coding, Post-coding, and Any/all. It just seemed more straightforward to consider the statements in a somewhat chronological order.

Here’s a taste of some statements that received the most votes, in order of how we might encounter them in a software development lifecycle.

Humans have a tendency to chime, “this time is different”, claiming that the old rules no longer apply and that the new situation bears little similarity to the previous ones. We’re often proven wrong, and we find that the present is simply a nuanced version of the past. With the new working agreement in front of us, the team started questioning its uniqueness. Is this project really a new kind of challenge? Is it different from what we’ve seen before? If our working agreement is so relevant for this new project, why would it not be for all kinds of projects? We reflected on the exercise:

• It was expected that Part 3, the brainstorming/ideation phase, would be lengthy and akin to pulling teeth. We felt the team might need prompting in order to pull information. We were wrong, and this part seemed to be both the easiest and quickest of the entire exercise.

• In Part 4, we thought the team would rely on me as the leader to combine and sort the statements. They ended up doing these steps mostly on their own. It was very helpful and indicated they were invested in what we’d created up to this step. 

• If/when we do this exercise in the future, a possible improvement to Fin, Part 4, would be to limit the number of stars each person can give. This didn’t seem necessary at the time, but it could help the team to truly prioritize the most important statements.

Upon completion of the exercise, the team decided to investigate potentially merging parts or all of our original team working agreement and our project-specific one. I’m not sure how our documents will look when we’re at a stopping point. My prediction is that some of the statements generated are truly unique to the new project, or are at least only applicable to a subset of projects we’ll encounter. What I do know is that because of the exercise, the team has a more relevant, effective, and significant working agreement landscape. And we feel better prepared to work together to take on the unknowns of our new challenge.

Next up: what’s the most effective way to enforce our Project-specific Team Working Agreement, and hold each other accountable? Well that’s…another story.