Remember that one meeting? The meeting where you were just peacefully sitting there, listening to someone talking about something indirectly related to a thing managed. Suddenly, you experience a surge of pain, shock, bewilderment mixed with a dash of confusion. Then, you ask yourself … “what just happened?!” You, my friend, were just thrown under the bus. I’m sure we’ve all been there at one time or another. For many, the first instinct is to draw your sword and fight the accusations hurled against you. Although this is a human response, it is often unproductive when building collaborative, productive working relationships. When the team takes a step back to assess where the breakdown occurred, the breaking point is often found at the intersection of lack of communication and assumptions made.
The thing is, many of us don’t realize there is an Agile tool that can help mitigate and minimize these occurrences. What tool is that you ask? It’s a Working Agreement - one of the most powerful, yet underutilized tools, in your toolbox.
A What?
A working agreement.
A working agreement is simply the documentation that captures an agreement between two (2) or more entities. It is a contract used in Agile software delivery to aid in establishing conductive, productive working environments for teams by communicating what each party needs for each team to be successful throughout the software delivery lifecycle. You may be thinking “Oh no! Not more documentation!” or “I’m not creating a contract!” Hang on. Hear me out. This is often an informal contract used as a framework and living document stored in a place that is accessible to everyone involved. The overall objective of a working agreement is to capture team expectations, define responsibilities, set up communication methods, and outline other elements essential to the team's success.
So, Do I Need One of Those?
Each of us have an idealistic working environment molded by our previous working and personal experiences, individual preferences, communication style and desired learning methodology. When working with others, the most common assumption made is that others need the same things you do to be successful. This assumption is rarely acknowledged, let alone addressed or discussed. This is one of the areas a working agreement can be useful.
Working agreements are most often executed between members of an Agile development team during project implementation. However, agreements can be between any group of two (2) people whose objective is to foster better relationships. This can be used for members on the same Agile team, 2 separate Agile teams, Agile team and stakeholders, implementation team and vendors, leadership teams, families and/or friends. Wherever, there is a value-add, really! This is agreement can be used as a tool to help get conversations started.
Ok. So, What Do You Put In One of Those “Things”?
Well … whatever the 2 groups decide. Here are some things to consider when establishing agreements.
- Agreement contains no more than 8 items
- Ensure the agreement has items that are most important to the team
- All items included are supported by each participant
Let’s explore the possibilities of what a working agreement may look like in 2 of the relationships previously mentioned: (1) an Agile team and Stakeholders and (2) Implementation Team and Vendors
- Agile team and Stakeholders
- Agendas provided for each meeting
- Provide clear requirements
- Feature demos are viewed by the primary and secondary stakeholder prior to release
- Treat one another with respect
- Stakeholders are available from 10am to 3pm to answer questions
- Implementation Team and Vendors
- Software updates are communicated in writing at least 1 day prior to release
- A response will be provided to emails within 4 business hours during normal business hours
- All API documents will be stored on the team’s wiki page
- Slack is used as the primary source of communication
- Arrive to meetings on time
The best thing about working agreements is that they are fluid. They can be implemented in a manner the entities deem best. One group may decide that adding the details of the working agreement to the internal project homepage is the way to go. While others may have a 5-line message pinned to the top of a Slack channel. Or a team may have the contents written on the write board in their shared environment. At the end of the day, do what works best for the team. But remember, selecting a universal location where the document is visible to everyone involved daily yields the highest level of success.
There are many free resources and tools available online that are helpful when creating a working agreement.
So That’s It, Right? I’m Done?
Well …that’s the starting point and you’re well on your way. Once a working agreement is established, they are revisited every 3-6 months, idealistically. Why? Because change happens. Evaluating the agreement on a consistent basis provides a space for the team to inspect what is working and what is not, then adapt. During the adaptation phase, you keep what is working and revisit the things that are not. The working agreement review also includes other elements such as new revelations and/or new factors present in the dynamic working environment.
Incorporating a working agreement may not solve all the problems in the world, or yours for that matter. However, it is a great starting point to set expectations amongst the teams and breakdown assumptions that can impede successful working relationships. Have an initial conversation about what everyone needs to be successful and having a document anyone can refer to can go a long way. Remember, working agreements contain items that the collective team needs to be successful, so hold one another accountable. Also, working agreements are not written in stone and should be revisited periodically to determine if current needs are being met. If not, adjust. If you have never tried using a working agreement, give this nifty tool a try. It just may be the perfect tool to help you stay away from those pesky yellow school buses that randomly show up in meetings.
