April 5, 2016

Working Agreements for Agile Teams (Part 3)

  —A team's working agreements reflect that team's values.

Curiously, I'm writing on branching policies again. In Working Agreements for Agile Teams, I discussed the problem with ambiguity. In Working Agreements for Agile Teams (Part 2), I discussed how the best working agreements are principles.

The issue of our prescriptive and ambiguous branching policy was raised and we agreed to rewrite it. This time I proposed

We agree to use topic branches for development.

This led to a discussion on why it's reasonable to disagree with this working agreement. For example, is it necessary to use a topic branch for a one line change? To improve a comment? My answer to these question is that it depends upon the code review.

We have another working agreement in which we agreed to peer review all code prior to merging it to the main line of development.

This led to a discussion on the interaction between working agreements. This discussion reenforced my thinking that good working agreements are principles and that reasonable people can construct arguments on when and when not to apply them.

I place a great deal of emphasis on product quality and what is merged into the main line.  Topic branches are irrelevant to product quality, although they can have an important role in ensuring it. In effect, my reasoning reflects my values regarding product quality and this reasoning motivates my choices.

If working agreements are principles and principles reflect values then what do your working agreements say about your team?