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.

Looking for an adult friendly movie that entertains the kids? Check out Big Hero 6.

In No iPad for Me I discuss why an iPad isn't useful to me. Recently, I had the opportunity to purchase and setup an iPad for someone. This allowed me to take a closer look at the iPad and to use it for my own purposes. Strangely, while I enjoyed using the device it wasn't enough to change my opinion.

After having set up and used the iPad I can say the device did not disappoint. I like it a lot. I am convinced that an iPad is ideal for web surfing (blogging!), email and watching videos. It's really nice to do these activities on a device that weighs less than my laptop.

Still, the convenience isn't enough to convince me to purchase one. The core issue for me is still that I already have two other devices and I don't need a third. It's not a replacement for my iPhone or MacBook Pro. I find this conclusion odd in light of the fact that there isn't anything that I don't like about the iPad—there really isn't anything that stands out and says “this device is inadequate”.

While I won't be purchasing an iPad for myself it's worth mentioning that the degree of integration between the services supported on the iPad, iPhone and laptops is truly amazing. Apple has done an excellent job of integrating iMessage, iCloud services and iTunes so that changes on one device are reflected on your other devices. I had no problems setting up these shared services and was able create a Shared Photo Stream easily.



Note:

The URL to the "Shared Photo Stream" is offline. It has been removed from this article.

I make a point of reviewing one of the GTD books by David Allen on a regular basis. My two favourite books are the original Getting Things Done and the more recent Making It All Work. I usually learn something new whenever I carry out a review.

During my latest review, I was re-reading the chapter on Control and came across the idea of bookmarking. Bookmarking is basically a benefit of practising and developing the capture habit. The idea is to capture what you are working on by taking notes while you are engaged in the task.

Bookmarking has two major benefits. First, it allows you to track where you left off and thereby create a bookmark for the task if you move onto something else. This is handy if you have multiple projects on the go and need to return to wherever you left of on a task at some point in the future. It will certainly help save time when you try and pick up a task and you need to remember where you where. Second, it helps you deal with interruptions.

Dealing with interruptions may be the biggest benefit of bookmarking tasks as you can never be sure when you are going to be interrupted and if you have the habit of writing down where you are when you do get interrupted then you never have to worry about loosing time by redoing work or trying to remember exactly what you have completed.