Agile teams own their process, or as we said in Disciplined Agile (DA), they choose their own way of working (WoW). Your WoW is your process, the flow of collaboration within your team. It also encompasses the artifacts that you use and create as you strive to produce value for your stakeholders.

Why Document Your Way of Working (WoW)?

There are several reasons why you may want to capture, or document, the team’s WoW:

• To help the team form effectively
• To be regulatory compliant
• To enable effective governance
• To support effective collaboration between teams

Years ago that might have meant weeks of effort to write extensive documentation that was likely to be ignored and allowed to get out of date. A more streamlined strategy is to create a team working agreement.

What are Team Working Agreements?

A team’s working agreement defines what the team does and how it intends to do it.  Often working agreements are informally defined and may be little more than a simple agreement between team members. At the other end of the spectrum a working agreement may be formal, even to the point of being a contract, for instance in an outsourcing situation. The point is that how you capture your working agreement depends on your context.

There are two aspects of your team’s working agreement:

1. Internal working agreement. This defines how the team will work together to accomplish the purpose that they have taken on. This part of their WoW should be completely determined by the team, although some aspects of it may be influenced by compliance concerns (see discussion below).
2. External working agreement. This defines how others may interact with this team, including what the team produces and when it does so. In effect this is the interface to the team, in technical terminology the team’s “API.”  A team’s external working agreement may need to be negotiated with their stakeholders to ensure that their needs are met, particularly when it comes to governance requirements (see below).

This delineation of internal and external aspects of your working agreement is an important process architecture issue. The internal working agreement is defined by the team and it should be cohesive, defining how the team will work together to achieve their goals. Because each team is unique they will have a WoW that is unique to them. The external working agreement defines how the team interfaces to, or interacts with, other teams. The goal it to achieve loose coupling between teams – teams interact with one another as needed and in a manner most appropriate for their needs.

How Do You Capture Working Agreements?

Agile teams will often capture their working agreement as a collection of principles or promises that they make to each other.  For example, I worked with one team that produced a list of eight promises that they made to each other about how they would behave – they would share their work, they would be open about how things were going, they would fulfill their promises, and so on. This was a very high-level working agreement for a team comprised of experienced people. It likely wouldn’t have been sufficient for a team of less experienced people nor would it have been sufficient for a contract between two organizations.

Of course, Agile documentation strategies apply:

• Keep it as simple as possible. The more complexity in your WoW the greater the chance of misunderstanding and of defects being injected in your work.
• Write concisely. I’ve seen effective working agreements captured on a single page. I’ve also seen 10-page working agreements that were understandable and just sufficient for the needs of the team.
• Keep the working agreement up to date. Once your realize that your actual WoW deviates significantly from your documented WoW, it is time to consider updating your working agreement to reflect how you’re actually working.

Working Agreements and Organizational Governance

A key aspect of the external part of your working agreement is how the team will support the governance strategy within your organization. Hopefully that strategy is lean and fit-for-purpose. To support your organizational governance strategy your external working agreement may call out these things:

1. Milestones. What are the major risks that leadership expects your team team to visibly address. For example, a software development team may be expected to show that they’ve come to a common vision early in their lifecycle, have identified a viable architecture strategy early, are on track throughout the effort, and have adequately tested their work before deploying it into production. These milestones may be defined by the delivery of specific artifacts, by a review, or through automated means.
2. Visibility. How will the team provide visibility regarding what they are accomplishing to their stakeholders? Will they support regular reporting, automated dashboards, regular demos, …?
3. Funding. How is the team being funded and how is the usage of those funds being monitored?
4. Delivery strategy. How will the team deliver their product or provide services to their customers?  How often will they do so?

Because governance strategies are often consistent across similar teams, your team’s working agreement may simply refer to the appropriate sections of your overall governance strategy.

Working Agreements and Compliance

There are two forms of compliance to consider.  First is regulatory compliance that you are legally obliged to conform to.  Second is organizational compliance, such as following common guidelines or adopting a common governance strategy across teams, that you choose to conform to. Either way, compliance will influence your WoW which in turn will be reflected in your working agreement. This may include:

1. Level of documentation. Some regulations, particularly in the financial and life-critical space, will define requirements for the documentation and evolution of your WoW.
2. Governance support. As described above, your external working agreement may reflect how your team will adhere to your governance strategy.

Evolving Working Agreements

When it comes to your internal working agreements, that’s your business. Some teams choose to formally revisit their working agreement, perhaps once or twice a year.  Other teams will update it on an as needed basis, often prompted by a change in their environment such as a new person joining the team and asking about how you work together.

When it comes to your external working agreement you will want to either negotiate any potential changes with your stakeholders or at least give people sufficient warning that your process is going to change. These sorts of changes are usually motivated by new demands made by your stakeholders or by changes to your WoW that enable improved levels of service by your team (such as shifting from a two week sprint to a one week sprint).