January 26, 2015

Working Agreements for Agile Teams

  —A introduction to good working agreements.

I’ve recently had the opportunity to introduce a software team to working agreements. This prompted me to question my notion of an effective working agreement. In simple terms, an effective working agreement is easy to understand, unambiguous and is used by the team.

A working agreement as an informal contract defining a team norm. A team norm is a behaviour that the team wants to develop or maintain. It is an informal contract to convey that the language can be informal but it must concisely describe the desired behaviour.

My view of working agreements has been challenged by a couple of agreements created by the team. In one agreement, a team member used ambiguous language to describe a branching policy. In another, a team member used numbered clauses to describe expectations for unit testing. In each case, the length of the agreement was a half page or longer.

Ambiguity is a problem if it leaves the expected behaviour open for interpretation. The working agreement describing branching required branching whenever more than a handful of files were changed. This prompted one commenter to ask how big the author’s hands were. Ambiguity causes misunderstanding and should be avoided. It defeats the purpose of introducing or preserving a behaviour into the team.

Formality is a problem because it raises the question whether one is adhering to the agreement whenever there is a legitimate reason to not fulfill a clause. Too much formality can move the agreement into an area where it describes rather than prescribes a behaviour. Describing a behaviour smells too much like a process for my taste.

A good working agreement to support branching is:

We agree to use topic branches for development and merge our patches to the main line after completing unit testing and code reviews.

This agreement removes the ambiguity regarding whether the branching policy is being used and when to merge patches into the main line—it’s a simple yes or no answer on whether the desired behaviour is carried out or not.

The use of “topic” is an open question.  It may convey too much information on a tool currently in use. It smacks of descriptiveness. A question like this can be posed to the team and left for them to sort out.

A better working agreement to support unit testing is:

We agree that an effective test suite addresses a single requirement (or use case). Said test suite explicitly identifies the high risk functional elements of an implementation and employs unit and functional testing to demonstrate the conformance of the implementation with the requirement.

This agreement has no ambiguity regarding the scope of a test suite, the focus of testing or the purpose of testing. In addition, it ensures understanding of the requirement for the unit under test and the identification of areas of high risk. These two properties help focus discussion on the requirement under test and where to expend testing effort.

There is a level of ambiguity in the definition of high risk embedded within this agreement. Namely the identification of a high risk functional element.

Rather than define this, I chose to try and develop a behaviour wherein the team identifies high risk functional components for each requirement. If the team focuses on testing the high risk functional elements of a requirement then the team is expending testing effort on the most important areas.  Furthermore, this empowers the team to conduct the level of testing they deem appropriate.

The length of this working agreement is an open question. Its length introduces complexity because it requires context to ensure correct interpretation. Context requires a high degree of internalization within the team. The degree of internalization could be an impediment for new team members. There may be advantage in breaking this working agreement into smaller components.

A working agreement should avoid ambiguity regarding the desired or maintained behaviour. It should be written concisely and the degree of implied context should be considered.

In coaching a team on working agreement, the appropriate action is to remain out of the discussion and provide guidance only when asked. In the case of the branching policy, the team decided to live with the ambiguity. We use code review on topic branches and not handfuls of files to determine when to merge. The unit test agreement is a work in progress and more discussion is required to level set and internalize context.