Working Agreements

You are in the middle of a great brainstorming session with your new team. Ideas are flying, everyone participates when you hear a ring. You hear in a hushed voice: "Sorry honey, I'm in a meeting, I'll call you back." Everyone stops talking to look at the culprit. The flow is broken. It takes a few minutes for the team to pick up where they were before.

Having a set of working agreements with your team can help to prevent this (and other) situations. Working agreements are behaviors that regulate all interaction between team members as decided by the team itself. This is very important: teams that decide their own rules are more likely to follow and enforce them. The act of deciding gives the team a sense of ownership. Working agreements can be discussed during a retrospective or if you don't do retrospectives (which you should), I guess you can do another meeting for them.

Once a team decided their own working agreements, it becomes easier for everyone on the team to enforce them, not just the project manager, team leader or other authority figure. “I did not appreciate when you were late to our pair programming session earlier today” is not understood as complaint about one’s behavior but as a gentle reminder of the rules the team agreed with.

Here are some examples of working agreements:

• The time everyone is expected to be at the office (9am-4pm or whatever fits your team). Outside these hours people have to be aware that some might not be available for meetings
• Usual lunch time (same principle as above)
• Time of daily meeting
• Meetings should begin on time
• Cell phones should be turned down during meetings
• Only one person at a time can be mad (I really heard about this one, it's supposed to allow people to vent while preventing others from shouting back...)

Working agreements can also be more fun:

• The person who makes the nightly build fail has to bring breakfast (pastries, donuts, fruits) for the team
• The person who makes a build fail is awarded the 'Cow of Shame' (or any ugly figurine) until someone else breaks the build

If the 'Cow of Shame' is ugly enough, your teammates will run the tests twice on their machine to make sure everything is green before committing their code... and so will you.