The basic unit of construction in the agile world - including organizations - is teams. For Scrum, for example, the Scrum Team is the fundamental unitand for the Scaled Agile Framework, it is the Agile TeamsBut what does it take to build a good agile team? Without a doubt, the first step is to establish solid working agreements.
What are work agreements?
In essence, a working agreement is a list of rules or qualities defined collaboratively and participatively among all members of an agile team. This list can include, among other things, activities, values or even rules to direct or modulate the behavior of each and every member of an agile team.
These documents - and I say documents because they must be written down somewhere visible or accessible to members at all times - avoid the unspoken commitments and informal rules of working with others.
Example of tacit or implicit agreement
To help understand the nature of the agreements, let's look at a simple example.
In this organization all meetings always start late. We are all used to them taking longer than scheduled and therefore, we do not feel the urgency to be on time if we are not going to leave on time in any case. It is a vicious circle.
This situation is typical in many organizations. Let's not forget that, even more so now with virtual work and the new normalBut is this a formal rule? If it is always or almost always enforced, does it mean that it is our way of working?
While it is difficult to determine the cause of this common practice in organizations, the question is: what can we do as a team to address it?
Explicit agreement
Teams can define a standard explicitly. Jointly agreeing on standards and discussing them openly promotes good communication and empowers the team.
In our example, the team can agree on rules in favor of punctuality and focused, on-time meetings, as follows:
As a team we value focused meetings that start and end on time. We always have meetings with a clear objective, communicated in advance of the meeting.
Importance of working agreements
Working agreements are a fundamental part of the team's identity. Who we are, what we do and how we do it. Every team starts with some uncertainty. Team members are unknown to each other, i.e., the rules of the game are not clear, how we are to organize ourselves to get the job done, whether we are going to use a hard-line model where tasks are assigned by someone else, or a model based on self-management.
Precisely for this reason, the earlier you define your agreements with your team, the faster you will be able to overcome this stage of uncertainty. known as StormThe sooner you can establish a safe space for discussion, communication and experimentation, the sooner you can establish a safe space for discussion, communication and experimentation.
How many times have you joined a team and don't know what your job is or how you should contribute to the team's goal? You may be clear about your own tasks or know what you are good at, but how we are to articulate ourselves as a team is not something you can anticipate, nor is it easy to get everyone to agree.
Relationship of working arrangements to agile teams
Working arrangements are not unique to agile teams. However, the agile mindset is focused on people and how they interact with each other. This makes it much easier to identify the benefit of using working agreements. Some attributes of agile teams that are in sync with team agreements are:
Equipment size
Agile teams are small groups of people. That means that participatory democracy is possible and easy to implement. You can include the whole team in a meeting room and work collaboratively on defining team agreements.
Not so with large groups of people. It is likely to be a more impersonal process, and therefore distant for many. This lack of involvement in the creation of agreements transforms them - for many - into mere informed rules.
Structure and hierarchy
Agile teams are, for the most part, devoid of complete hierarchies or deep political structures. This makes the team more participative and risk-taking - viewing risk as the uncertainty of taking on new challenges or adopting new practices.
Working agreements help teams with a simple, flat structure to take "accountability"The company's own work model.
Autonomy
Another quality of agile teams is the autonomy to define "the rules of the game". While agile teams should not go against the rules, they can "bend" the boundaries a bit by setting their own rules.
Well achieved, autonomy can be a productivity and confidence booster for the team. This is key to unlocking the team's potential through so-called "psychological safety".
How to define agile working arrangements?
The first and most important thing is to clearly establish that the word agreement involves several parties and this means that the process must be collaborative. Defining the working agreement is a joint effort of all members and not a task that we delegate to the project manager or Scrum Master.
If you want to facilitate within your team the construction of a working agreement, I recommend:
- Knowing the team's objective. What is the raison d'être of the team?
- Identify the people in the team, their roles and the reason why they are part of the team.
- To call for the session - face-to-face or virtual.
Once the day and time are set, don't forget:
- Define the tool to be used. If it is a face-to-face session, do not forget to reserve the space - meeting room or auditorium - and prepare the materials required for the activities to be facilitated. If it is a virtual session, you can use a tool such as Miró or Mural.
- Establish a base structure for discussion. While facilitating is not directing, establishing a contextual framework to modulate the discussion and achieve baseline agreement is key. You can do this by using the Team Canvas o Team Charter.
- Imagine the flow of the session - how much time is required to complete each of the activities you set out? Then you can define the time periods for each activity. timeboxing. Remember that if the activities are not limited in time, the participants will be dispersed or will not be able to concretize ideas or proposals.
- If the team is meeting for the first time, or you are not sure if everyone knows how to use the selected tool, you can do a short icebreaker or support task so that everyone is clear on group dynamics, time management and tool use.
- Let the team work. The team should work alone, without your constant intervention. However, constantly check that everyone is participating and try to avoid having one person do all the work.
- At the completion of each activity, you should allow time for the team to present their conclusions or findings. Prepare some key critical questions to validate that they understand the impact of each proposal - how does the team benefit? what impact does it have on others, inside and outside the team? when and how will we implement it?
Every agreement and every conclusion must be formally discussed and documented. And documenting is not generating a document of thousands of pages, it can be something simple and light as a small poster or infographic. The important thing is that it is not just words in the air. Let the team review the outcome of their work and consolidate their own final version of the working agreement.
What are the most popular types of agreements in agile teams?
Well, in agile teams there are many types of tacit and explicit agreements and rules. However, the most popular - or commonly used - agreements are:
Team Constitution Act
This document - known in English as Team Charter - is a document or graphic representation - such as a poster - of the team's values, objectives and guidelines or rules that the team itself has defined for itself.
These minutes are created by the team members themselves and cannot be imposed. As the saying goes, "authority can be delegated but not responsibility", since responsibility can only be "accepted". In other words, we want the teams to be responsible and feel that they are the owners of their own rules.
Typically, these types of teamwork agreements include:
- Team mission and objectives - why and what we are together as a team.
- The context and resources we must have to do our work and achieve our objectives.
- In many cases, in organizations with more conservative values (compared to the agile mindset) clear roles and responsibilities are included - as the spirit of "co-responsibility" or "shared ownership" of achievements and challenges does not yet exist.
- Processes, procedures and techniques to use. How do we commit to do or guide our work? Discussing quality, good manners or ways to do our work and that the commitment is from all members is key. Otherwise it is another document with rules that everyone ignores.
Definition of Completed - Definition of Done
I dare say that this is the most popular and misunderstood instrument of all. According to Scrum Guidethe Definition of Done is a formal description of the status of a deliverable or increment in Scrum when it meets the established quality requirements. When we refer to the concept of quality, this conceptually includes assurance and control. But what does it mean to meet quality requirements?
Definition of Completion and Acceptance Criteria
The Definition of Completion refers to the general criteria associated with the requirements production process - or backlog elements if you are in an agile context. Acceptance criteria, on the other hand, are specific to the specific requirement. To better understand, let's go with an example:
A team whose job is to generate informative content for a Web site specializing in travel has agreed on the following Definition of Completed for each article: (1) it complies with the style guide; (2) it has no spelling errors; (3) a peer has done a proofread and comments have been addressed.
This week, one of the people in charge of writing an article is working on Spain as a tourist destination. Among the acceptance criteria is to talk about the capital of the country, to include in the article the impact of the Arab periods in the Spanish territory and how this is reflected in some cities, in its architecture and gastronomy.
This example is very simple. And it evidences the two concepts. The definition of completed is a joint team agreement that promotes the quality of the deliverable. And this can include steps to "prevent errors from being made" - quality assurance - and steps or checks to detect defects or errors early - quality control.
Common mistakes when creating a Completion Definition
Among the most common errors in creating a definition of ready include:
- Have an extensive list that attempts to address every scenario - the list should be practical and applicable to all requirements, but never attempts to address every special case.
- Confusing acceptance criteria and incorporating ad hoc requests into the definition
- Failure to formally communicate the definition or publish it clearly somewhere - printed on screen or on a collaborative work platform.
Definition of Ready to Run - Definition of Ready
This is a slightly less popular instrument, but no less valuable. If we imagine that the Definition of Finished as an output checklist (delivery), the definition of ready to run (ready) would be like an input checklist.
When should I use the definition of ready to run? Here I tell you:
- Do you have problems completing functionalities or requirements that have not been clearly defined? This tool can help you agree on certain acceptance criteria.
- Your team doesn't know when they should consider a requirement for work? This artifact promotes clarity and avoids arguments about what to do and what not to do.
Similar to what happens with the Definition of Completion, you should avoid being excessive with the details. It is about setting clear rules about the level of detail and what should be fulfilled to be accepted in a schedule - for example, a Sprint in Scrum.
5 keys to consolidating good working arrangements in agile teams
Here are some useful tips for building better teamwork agreements.
Contemplate technical and personal aspects
Teams have a focus or objective. Often that focus is limited to technical or work-related activities and not personal. However, high-performing teams do not limit their commitments to work and recognize the importance of the other person. This includes, among other things, cultural expressions, behaviors or even attitudes - for example: how to greet, how to address political or religious issues, attitudes towards feedback or handling problems and conflicts.
Keeping the agreement simple
Agreements should be easy to remember and follow. An agreement should not be a lengthy contract, but a clear way in which each team member commits to his or her teammates. Agreements do not replace value statements, nor does every group agreement need to be in the same document, so keep it simple.
Update agreements on a regular basis
While an agreement is meant to be honored, it is also important to understand that the context evolves and that sometimes it is prudent to revisit our agreements and give them an update. Sometimes this comes naturally to the team, or it may happen when a new member arrives.
Raising your hand when the agreement is not fulfilled
This case is rarely considered. Who creates an agreement to breach it? But the reality is that the mechanism or channel for evidencing or reporting what is considered a violation of the agreement should be discussed during the creation of the agreement. It does not have to be very complex, but it should be clear to all team members how to expose what they consider to be a violation of the agreement. Also, discuss with the members the way to handle that report or non-compliance. This should be agreed early on to avoid later headaches.
Linking agreements to the organization's value system
Unless you work in a horrible organization, work agreements should always tie into the context of the organization and its values. This doesn't mean copying the values verbatim, but definitely finding an anchor will allow your agreement to be consistent with the organization. Your team may not be part of a large organization or even apply, and in this case, establish a small value system - like Scrum or XP does.
