Using a working agreement in your agile development team

The concept of a working agreement has become common place within agile development teams, but what is it? Why is it important? Who is the agreement between?

For a team to work:

• they need to be committed to the success of the whole - have a Goal
• they need to subscribe to the concept of collaboration and co-operation – subscribe to a set of localised working practices
• they need to be accountable to other members and a wider organisation (context) – work to an agreed set of policies and procedures

To achieve this, there are three aspects that need to be considered; a Goal, the Working Agreement itself, and the supporting Policies and Procedures.

The Goal

You an agile development team and the working agreement is about creating a team culture; a mutual commitment and reason for individuals to work together to reach a common goal, for a common purpose.

The Goal is the focus for the team, the reason it exists. It should be understood by all and displayed for all to see. Without a goal or purpose, you don’t have a team; you have a group of individuals, that’s sub-optimisation.

The Working Agreement

By definition an agile team has a high amount of daily interaction. This brings out a need to establish a common set of rules that all the team members abide by. A Working Agreement fulfils this by helping a self-organizing team to establish and codify behavioural standards on how they will work together; without having them imposed from the outside. It is as Jean Tabaka notes, a team’s declaration of it’s self governance. If you don’t get this agreed it can result in conflict through tacit approval that a particular behaviour is acceptable.

Israel Gat defines some Key attributes of a Working Agreement for the agile development team as follows (to which I have added a fifth item):

• Created and changed by mutual agreement (i.e. the Team members)
• Enforced by mutual agreement
• Outside of an Organisation’s agreed policies and procedures
• Made between peers
• Exists for the life of that Team

XP defines a Working Agreement during the Project Charter phase, establishing how the team will work together as effectively as possible given the constraints of the project. This includes Practices and Standards.

The Policy and Procedures

But, if a Working Agreement sits between members of the team there is a gap. Is a Working Agreement by itself enough? How effective is a Working agreement when it is simply a set of written comments agreed between peers, when the wider organisation has not been included? What about a Social_contract, an agreement between the team and its encompassing organisation; with management, or between the team and business. i.e. the Team will undertake xyz in return the Product Owner will commit to xyz and Management will commit to xyz.

The Working Agreements should focus on the team. But that does not mean we should be insular and exclude management. Kanban makes the Policies and Procedures explicit - we are including management and creating a Social Contract which fills that void; in effect it becomes that Social Contract.

(N.B This is where I differ from Israel Gat in that I believe his Social Contract example should be applied across the Working Agreement and Policies and Procedures. He has some great material on Working agements.)

What should be in a Working Agreement?

Here is some example working agreement items that I have used in the past, this includes team interaction. I've tended to break technical practices and coding standards into a seperate set:

• Update team board before the daily stand-up
• Be present for a core set of hours:  10am to 4pm
• Communication in this order: Face to face, phone call, Instant Message then email
• Publish phone numbers and open and share calendars
• He/she who breaks the build fixes the build !

I find it very important to include the Product Owner availability in my Working Agreement. We need to extend the Working Agreement to get commitment from them as to their availability and what the team expects from them. (I don’t want a full time product owner but that’s the subject of another blog...).

• Product Owner availability (contact details, availability, attendance in Daily Stand Up)

The key thing is include the Product Owner in creation and agreement of the Working Agreement. They are a key member of the team.

I used to include in a Working Agreement Policy items, specifically WIP Limits ‘Work on only one item at a time, but if you are blocked, then work on a second item'. I realised this should become part of an agreed policy and procedure. By limiting WIP in a Kanban approach we can visualise this on a Team Board. The agreement to not over commit the Team needs to include management. To ensure they do not introduce additional work outside an iteration, or break agreed WIP limits, they need to understand the implications of their decisions and have brought into that Social Contract.

Jean Tabaka even takes the Working Agreement a step further, with the concept of Ground Rules. These are for use within meetings and general team interaction (which should include Pair Programming) and include items such as:

• Respect the speaker
• One conversation at a time
• Mobile phones on silent
• Start and Finish the meeting on time
• When Pair Programming, turn off distractions (email, IM)

I have not tended to use these explicitly, but they can be useful for large teams and for posting on the wall each time you have a meeting.

In Summary

The working agreement forms part of the social contract and reason for the agile development team working together. The three key aspects as I see them are as follows:

The following is a set of steps to keep in mind as you construct the Goal, Working agreement and Policies and Procedures which will form the basis on how you team will work and interact with the wider organisation.

1. Set a Vision and Goal so that the team has a purpose
2. Risk Assessment and practices selection for the Team
3. Define a Team Working Agreement and post it on the Team Board
4. Agree between the Team and the Organisation (Management and Business) a set of Policies and Procedures. Make the statement “We have an Agile development process and we all agree to adhere to it”. Management and the Business must sign up for this and see the implications of any decisions that they may make
5.  Publish the set of Policies and Procedures on the Team Board and make them explicit for all to see and adhere to. This is your Visual Control.
6. At the far right of your board, should be your Team’s agreed Goals; that’s why you’re doing what you’re doing, isn’t it?
7. Define Definition of Done and Definition of Ready: we need to know and circulate how we expect things to come into the process and how they exit
8. Inspect and Adapt. Review your Working Agreement and Policies and Procedures as part of your Retrospective.