You probably have plenty of teams to watch over, but does everyone know what’s expected of them? How many devs are still holding onto their own processes or expectations? How many just go with the flow and hope for the best?
Unfortunately, winging it isn’t sustainable and could lead to employee burnout. If devs aren’t sure what is expected of them (especially new hires), they could waste time and energy, adding tension to an already stressful situation.
This is where an agile team working agreement can help. This article will talk about what team working agreements are and how you and your leaders can ensure your teams are following best practices. Let’s dive right in.
Table of Contents
- What Is a Team Working Agreement?
- Why You Need Working Agreements
- Best Practices for Establishing Agile Team Working Agreements
- What to Include in Your Team Working Agreement
- How to Enforce Team Working Agreements
- Team Working Agreements Help Everyone Improve Together
What Is a Team Working Agreement?
Team working agreements are clear expectations and guidelines on how your dev teams should work together day-to-day. These agreements can be as simple as “never push to the main branch” or tackle more complex things, like how a team wants to structure its PRs.
Team working agreements are like a living document, where team members clarify how they expect work to happen and set rules about how they collaborate together.
They can be a strong foundation for new devs on a team, but they’re also highly beneficial for all teams, no matter their level of expertise or years spent working together.
Why You Need Working Agreements
By adopting working agreements, your teams and team leaders will benefit from more effective communication and quick resolution to issues. Also, having team working agreements will help the individual teams and engineering org as a whole align on best practices.
Team members don’t always have compatible working styles or expectations for how others should act. And it’s likely that no two teams in your org work the exact same. But for an engineering org reach its goals, there are some things that all teams and individual team members need to agree on.
When you establish team working agreements, you can clarify expectations across multiple development teams (and within individual teams) when needed. And when everyone knows what they’re expected to do, they can perform better. For example, working agreements:
- Promote a culture of shared accountability
- Encourage the discussion of both good and bad behaviors
- Motivate the scrum master to hold their teams accountable
- Create a positive work environment
- Maximize your teams’ engineering efficiency
If set up strategically, team working agreements can directly correspond to (and help improve) key engineering efficiency metrics that your execs and board members care about.
Best Practices for Establishing Agile Team Working Agreements
Team working agreements are all about developers, so you need to implement them in a way that works for them. So, here are a couple of best practices to follow when creating team working agreements:
Let Teams Collaborate to Create Working Agreements
When teams create working agreements, it’s best to have all team members collaborate. Your team leaders should be guiding teams to flesh out a collective idea of how everyone expects work to be done. Let them work with your dev teams to lay out clear examples of what they all want to see.
A working agreement is only as strong as the teams working with it, so let them decide how they want to get things done. And when everyone feels like they have a say in how they work, you’ll be fostering a positive developer experience.
Keep Team Working Agreements in One Location
Most engineering organizations have company-wide policies and procedures for team members to follow. But team norms might be scattered in more than one place, and working agreements might add to or change some of them. That’s why everybody who needs to know how your teams work should be directed to the same place.
A team-specific document is a great way to summarize all considerations. It also keeps new members joining the team informed. But beyond that, you can benefit from having a centralized place indicating how your teams should operate. This can come in handy if you need to investigate why some processes may be more efficient for other teams, for mediation between teams, and for business continuity.
What to Include in Your Team Working Agreement
But what can you include in a team working agreement? Here are some things a team working agreement can address:
- What are the guidelines for communication?
- How are decisions going to be made?
- If there is a disagreement, what steps should be taken?
When evaluating a project, what metrics should be used?
Making a team agreement can help ensure everybody is on the same page about what to do in different scenarios. In the long run, this will prevent unnecessary hassle.
Working Agreement Examples
Your teams should include all ground rules, guidelines, or expected conduct in their working agreements. Here are some key components to include in a working agreement:
- Meetings: Start and end on time and stick to a schedule. Scheduling too many or extended meetings can pull your devs out of productive flow states, decreasing productivity.
- Transparency: Don’t keep any secrets. Members should offer feedback, accept it, and respond to it. This will help build accountability and better follow-up and follow-through in your engineering org.
- Code reviews: Maintain a PR size of fewer than 225 lines of code to facilitate faster reviews and deployment. Big PRs can create a severe bottleneck, where your dev teams often miss deadlines or curb efficiency when they sit too long in review.
- Bottlenecks: Address any internal issues that have been causing delays. Hint: it’s probably your PR lifecycle, so set team goals around how quickly PRs should be picked up and reviewed.
- WIP limits: Never have more than four stories in progress simultaneously. It’s better to wrap up an unfinished story than to begin a new one that won’t be ready for the end of the current sprint.
- Jira ticket hygiene: Link all merged commits to their respective Jira tickets. This ensures that unplanned work gets documented and you have accurate data if you use Jira reports.
How to Enforce Team Working Agreements
Working agreements that aren’t followed are pointless at best and potentially destructive at worst. If you have weakly enforced dev team policies, people may feel they’ve been implemented just for show… or that your engineering org isn’t well managed.
Here are a few ways to ensure your teams follow their working agreements:
Monitor Team Health
Your devs aren’t robots. You can’t lock them in a room and slide pizza under the door once a day until the project is complete. Maintaining a positive developer experience means taking the dev team health into account. By keeping your teams’ health a priority, you’ll prevent burnout and improve productivity.
With LinearB’s Teams dashboard, you and your team leaders can gain insights into your team members’ health and well-being and have better information to directly improve it. This way, you can manage each of your team member’s WIP, active days, and other metrics that you may have agreed to in your team working agreements that can cause burnout.
Set & Celebrate Team Goals
Once you’ve established a working agreement, you should monitor how well your team is sticking to it and celebrate when teams are collaborating well.
For example, with LinearB’s Team Goals, you can set custom goals for 7 types of working agreements:
- Prevent Long Reviews
- Avoid Large PRs
- Keep PR Lifecycle Short
- Review PRs on Time
- Only Merge Reviewed PRs
- Don’t Merge PRs with Basic Reviews
- Avoid Merging Risky Work
Maybe your teams have read our Engineering Metrics Benchmark study and have agreed to keep PRs small (specifically under 225 lines of code). Your team leaders can set up that Team Goal and then track what percentage of their teams’ PRs meet the criteria in their Team Goals Dashboard.
When you can give your engineering leaders and devs a visualization of how they’re performing, they’ll be more motivated to succeed. And when they’re close to hitting their goals (we suggest around 80%), it’s party time! 🎉
Celebrating your teams’ progress can be a huge boost to their morale and productivity, and Team Goals allows them to see their hard work pay off — that their efforts didn’t go unnoticed.
Automating a working agreement is the most effective way to ensure everyone consistently sticks to it. It’s typically more cost-effective than getting everyone on the team to spend time and energy changing their behavior.
For example, if you discover that your PRs are getting stuck waiting to be reviewed for more than a day, LinearB not only lets you set a Team Goal for that, but our developer automation tool, WorkerB, can warn your teams via Slack or MS Teams that a PR has been left hanging.
This automation takes tedious micro-managing tasks off your team leaders’ plates but still ensures your devs hit their goals. And as a plus, when you make it easier for teams to get work done, you’ll maximize their efficiency, so they’ll be giving much better outcomes for the business.
Team Working Agreements Help Everyone Improve Together
Your dev teams can gain so much from working agreements, enhancing collaboration and productivity, and contributing to the betterment of your entire engineering org. And when your teams are on the same page about what they want to do, they’ll be more satisfied, they’ll be more likely to meet their commitments, and you’ll see higher quality output overall.
But you need to know how to implement and enforce team working agreements for them to really work. And to know whether your teams are succeeding in this regard, LinearB gives you and your team leaders the power to track and visualize key parts of working agreements. With Team Goals, you can back up your working agreements with raw data to help your teams see the steps they need to take to be more productive and celebrate wins when they work and grow together.