Work agreements are often used in the Agile context, but can be used by any team. Through the work agreement process, teams are given an increased awareness of the interaction between individuals. Another challenge for many time zones is that people who start their day earlier than others often continue to work after the end of their day, as they try to spend so much time with the team and not give up something critical. While this is proof of commitment, it is not sustainable in the long run. At some point, people start to burn and finally, the quality of the product, with their own health and well-being, will suffer. A similar charge will occur upside down for team members who are forced to start their day in the middle of the night and work in a later time zone until the end of the work day. If you opt for a team work agreement, the most important thing is to make sure that your team is fully involved in the whole process. Make sure it is addressed to all “itchy” or uncomfortable topics and that the agreement is placed in a place that is easily accessible to the team. Pass and vote to maintain or modify existing agreements. Then the team members brainstormed, proposed, and voted on the addition of other agreements.

The Agile team consisted of 11 people, working both locally in Texas and remotely in Mumbai, India. Local members of the Texan team included both MS and PO, as well as two engineers: a tech-lead and a senior developer. They worked from home three days a week, but would be at least two days in our headquarters. The SM and the PO were almost always present at the office. The India team consisted of seven engineers, one of whom was the supervisor and effectively our team leader in India. The other members of the Indian team had various other roles in the development of our solution. The team approached the end of the current sprint and would keep its team in review the next day. Fortunately, the timing worked. I was invited to participate in the retrospective and meet the entire team that Steve is starting to ask for proposals for agreements in his first area of priority: Daily Scrum Start Time. After any possible work agreement, it uses the Decider protocol[2] to quickly examine the possibility of consensus. If there is no immediate consensus, the person who said “no” to an idea suggests what they see as a better idea.

If more than one person has a problem, everyone is expected to offer a better idea. If too many people say “no,” the applicant should consider withdrawing the proposal. In the case of Steve`s team, the team has the first work agreements after 20 minutes: make the agreements together with the team and combine similar agreements into an agreement. Now that you have the basics, here are examples of some clauses that you could include in your teamwork agreement. Some of them are specific to agile teams. Provide a secure space to discuss what worked and what doesn`t. As I wanted to do SM to facilitate the process, I coached her to create a list of questions for each value, to generate a discussion and to help teams decide on all the “rules” we should create to ensure that everyone respects that value. We didn`t care where the answers were placed as long as they were captured. The SM asked the questions and collected the answers, while the team voted on the points to be formalized in a working agreement.