Five common problems with team working agreements

Working agreements are an essential part of healthy team dynamics. They’re guidelines which align the team on how work is done. They can contain anything from aspirational team values to low-level coding practices. If product work is a balanced meal, then working agreements are the vegetables, so you shouldn’t skip them!

Let’s talk about these five common pitfalls that can turn your veggies into a bland and mushy mess.

They’re not discoverable enough

Your team releases to production every week, and it’s your turn to send out release notes and get stakeholder approval. The goal is to ensure that new features don’t catch these stakeholders by surprise. You can’t find the relevant working agreement and the list of stakeholders, so you ask around and get different versions of the list and pick the one that seems right. After releasing to production, someone else points you to the relevant working agreement, which contains a stakeholder you never contacted.

Problems like this demonstrate why working agreements are even necessary at all–they are meant to assist teams in meeting their goals. In our example, the stakeholder we missed may be surprised about the new release.

Your team will produce a lot of different types of documentation. It’s not practical to keep everything in your head or rely on your teammates to help you locate the right file. Your working agreements need to be well-documented and easily discoverable.

Each team must reach their own conclusions about how to organize their working agreements and where to store them. There are no wrong answers—it comes down to what works best for the team. Many document stores also have their own search indexes, which can help with discoverability. Wherever they are stored, I like having artifact links attached to the activity or domain in question. In our production release example, a recurring calendar event with a link to the working agreement would have been useful. For Slack or Teams, consider pinning working agreements to channels or embedding them in reminders. As a bonus, consider document stores that are versionable, so that team members can reconcile if working agreements recently changed.

They’re not changing

Over the course of a project, goals will evolve. If your working agreements aren’t changing with them, they may start adding friction. Working agreements are meant to facilitate collaboration. They should be revised or dropped as soon as they stop helping.

Misaligned working agreements are not always simple to identify. Team retrospectives are a great place to bring up issues and see if they’re related to a broken or missing working agreement. Old agreements may solve a problem that no longer exists.

You don’t have to wait for a retrospective to revisit working agreements. Asynchronous communication over chat can be a great way to discuss problems, solutions, and make consensus driven revisions to working agreements.

They’re not being occasionally ignored

This may seem counterintuitive. How can we consistently meet our goals if it’s okay to ignore the rules we’ve set forth?

That last sentence isn’t quite right. Working agreements aren’t just “rules for rules’ sake”. They simply capture a consensus on how a team agrees to work toward a set of common goals. Software projects are full of surprises, such as deviations in the delivery cycle. There may be moments where they don’t meet (or even interfere with) the intended need. In these situations, we should consider ignoring them.

This isn’t as simple as just doing whatever you want! If you’re encountering a problem with a working agreement, tell your team and build consensus about what to do. Allowing for flexibility around revisiting working agreements is a great way to build team trust since you get to solve a new problem together.

Does this mean the rule is broken? Not necessarily. If the rule works well most of the time, you may not want to change it just because it’s not perfect.

They’re not automated

We’ve covered that remembering working agreements is hard, so why not reduce the number of working agreements that must be remembered? We should always strive to apply our working agreements to our tools. The tools at play depend on your role; it could be a document template, Figma components, or developer build tools.

Developers in particular have no shortage of automation opportunities. While you might normally write tests for your code, what if you wanted your project to have test coverage of at least 90%? You could implement an automated test coverage measurement as part of your Continuous Integration suite to satisfy this working agreement.

Some working agreements may be more subjective; if you have a working agreement of “we will pair program and/or seek peer approval for new code contributions”, you might require peer approval for a pull request in Github. For a working agreement like “we will not greatly increase code complexity to future-proof”, this gets trickier: do we assert this with static analysis or continue to lean on peer review? Ultimately, your team has to determine the right blend of automation for your working agreements, since the wrong automations cause your agreements to become inflexible.

If automations are simple to apply, use them liberally. They are especially useful for working agreements that tend to be forgotten. Sometimes even a Slackbot reminder is enough to help convey the working agreement at just the right time.

They’re not mapped to problem statements

Your working agreements should be mappable to goals and/or problem statements. Not knowing the rationale behind a working agreement can be killer to team “norming”.

Team members develop best practices over their time together (e.g. “format commit messages in the present tense” or “always write acceptance criteria with a because clause”). When multiple members share best practices, they tend to blur them with working agreements, sometimes leading to unspoken working agreements.

This can lead to undocumented working agreements that are borne out of habits, rather than stated project goals. When new members join a team, this can cause friction if they believe in contradictory best practices (“format commit messages in the past tense”). A likely outcome is that incumbent members are frustrated at the new member’s approach to work, and the new member in turn is confused.

It’s worth the extra time to map working agreements to problem statements. This helps the entire team build consensus on whether there’s a problem, and if so, where working agreements can help resolve it. A great example is your release cadence: how did you choose it? Are there certain days that you avoid releasing features, and why?

Missing problem statements also make it difficult to tell whether an existing user agreement is serving its intended function or if it should be revisited.

Takeaways

Working agreements aren’t a one-time exercise. Spending time and attention on them will produce long-term savings and productive team dynamics, and allowing them to flex gives your team agency. The essence of an Agile time is to observe the conditions of a project and adapt to them; working agreements illustrate how your team is listening to the world around them as well as the people inside of them. If your team keeps eating their peas and carrots, they’ll grow up to be as productive as possible!