Whatever methodology your team uses, a working agreement is a crucial component to set the expectations for what it means to be part of THIS team. I believe that every team, no matter if it has 2 or 10 people - should have one, and it should be adapted when you have new people join the team.
Here’s a quick low-down of how to create one and stick to it!
What?
Developed BY the team, FOR the team. They are a set of rules that each team member agrees to follow to prevent bad habits from inevitably creeping in over time.
Why?
As the team comes up with the rules themselves, it helps towards their shared ownership and self-organisation. Additionally, it creates an awareness of both positive and negative behaviours that can impact the team, and is a useful tool to refer back to when someone in the team starts breaking the rules. In the past, I’ve worked with individuals calling themselves a ‘team’ but in reality there’s a completely different expectation from one individual to the next.
How to create a working agreement?
It really doesn’t need to be a long session (in my experience it takes a max of 30mins), but everyone who is part of the team should be present. I’ve experienced having just 1 team member not present leading to all sorts of chaos and bad behaviours.
I took inspiration from a webinar I attended which was hosted by Lisette Sutherfeld who created a template based on the ICC Workflow Audit, created by Phil Montero, founder of The Anywhere Office which allows us to focus on 3 key areas:
Information
- What kind of information do we need in order to develop our products or services?
- This can incorporate ticketing systems such as JIRA or Zendesk, wikis such as Confluence or an intranet as well as any security issues (e.g. does company policy prevent us from using tools hosted elsewhere such as Google Drive and Dropbox?)
Communication
- This covers the type of communication we need to get the work done - in person, phone calls, video calls etc.
- It’s also useful to consider our expected response time for each method of communication in this step.
Collaboration
- Team size, location (especially in regards to time zone differences) should be considered as part of collaboration
- Useful questions to ask include:
- What are our core hours?
- How do you know what other team members are doing (e.g. daily standups)?
I usually start by asking each team member to write down at least one expectation per category onto a post-it note and then discuss as a team afterward. The important thing to remember, is that the agreements should be simple and easy to recall.
Results
Here’s the team agreement for a newly established team who I had the pleasure of facilitating their working agreement session with recently:
Information | Communication | Collaboration | Tools |
---|---|---|---|
Clearly defined requirements as stories in Trello | Daily stand-up meeting | Pair Programming | Trello - communal board and transparency |
Detailed information/product specifications stored in shared Google Drive | Reduce email - use Discord or Skype to communicate daily | Core hours: 09:00 - 15:00 GMT | Google Drive - detailed specifications |
Expected response time: 24 hours | Team sets own Objectives and Key Results (OKRs) | Discord - everyday communications | |
Meet in person every 3 weeks | Skype - everyday video conferencing | ||
Retrium - fortnightly retrospectives |
How to stick to it?
I’m a fan of creating posters and displaying them in the team space where possible. However, this can be a bit more tricky with distributed teams. In which case, I always create a wiki page (for example, via Confluence, or Google Docs) with the rules which is pinned to the team’s main communication channel (I’m currently a big fan of Discord). Any time someone within the team feels that other team members aren’t sticking to the agreement, it is raised as a discussion item or brought up at the next retrospective (if you don’t have regular retros, you should at least be having regular team discussions to address issues such as this).
Next steps
Following the creation and distribution of the team’s working agreement, I like to move on to looking at interaction maps to identify who the team depend on most. Check out my other blog post for guidance on how to create the interaction map.-