In Working Agreements for Agile Teams (Part 5), I focus on how using principles improves interaction, despite apparent disagreement within the team on the correct interpretation of the design working agreement.
What I learned from this was that the emphasis embedded within the agreement was on the interaction required by the design activity. It’s focus was not the design itself or even the “efficiency” of the activity. It was about encouraging an interaction in a design context with the goal of ensuring knowledge transfer and learning.
Could this working agreement have been written as a prescription, describing the required interaction and learning? It could be, but then it needs to be written like a procedure.
A procedure contains a set of prerequisites describing the scope of the procedure and a set of ordered steps describing what actions to take. It prescribes what is required in order to complete it.
A procedure could enforce the interaction. For example, it could contain a perquisite: gather two of your peers. Easy enough.
What about the case where we are “designing” a one code line change in a function. A procedure would have to specify what do do if a design isn’t required. Is this another prerequisite? Perhaps.
What about the case where we are designing a one code line change with profound implications? Does such a line exist? Let’s assume it does. Let’s say there is disagreement over the importance of this change. Our hypothetical procedure just got bigger, harder to read and importantly, unlikely to get read.
So I’ll stand by the notion that good working agreements are principles because they force interactions. People, when motivated to achieve a goal can figure out the rest.