These agreements are drawn up by teams and scrumMaster facilitates the meeting, and they are created/verified preferably during the Sprint 0 of each publication. Remember, every team is different. The clauses that work for my team might not work for you. So you come up with your own style and find out what works for your team. I had never been a big fan of employment contracts. Of course, I knew what they were, I knew what they had to do, I had even integrated one or two versions into some Agile classes that I had taught, but I never understood how powerful the development process of it can be! To keep the debate on track, use facilitation techniques such as fist of five to reach consensus on all labour agreements. The first step in this process is to set the scene for your team. Give them an explanation of why this document can be valuable to them, and what the process will look like. Then start the process! Ask the team to answer the following question: what decisions, if made now, could help us in the future if the pressure on us is baptized or if things have not gone our way? For other readings and examples of employment contracts, we recommend that the labour agreement define team standards or disciplines, as they do here.
They go on to say, “The purpose of the work agreement is to ensure that the Agile team has a responsibility to set expectations about how they work together and to improve their self-organization process.” At the end of the day, it doesn`t matter what you call. What matters is that you have it. ME, without strong work agreements, scrum teams rarely perform at high performance, because team members rely on standard expectations of what is considered “professional behaviour in the workplace” and “manifest common sense.” If the Scrum and Agile teams want to achieve high performance (the standardization and performance levels of the Tuckman model), they must consciously create their team culture. Working agreements are a tool to help them do so. Teamwork agreements should describe how team members work together to create a positive productive process. For each team member, the only way to do that is to add their two cents to the development of these policies. The views of all members are important and inclusion is the glue that keeps the agreement in common. 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.