—Using Working Agreements as Principles leads to Values Discovery
In Working Agreements as Principles, I discuss my continued belief that good working agreements are principles and provide an example on why. I’ve long suspected that this approach eventually leads to uncovering a team’s values as well.
I’ve been using the working agreement as a principle with the last two software teams I worked with. Their use with the first team, lead to the personal realization that I value good code review above some other activities. The second team took 14 months to get from principle to values in relation to code review. I believe that the introduction of BitBucket and transparency around code review prompted this change. (Both teams used BitBucket, although the first team started with Review Board.)
So here I am. Fourteen months after the introduction of the working agreement on code review I am about to embark on a discussion on values. Here’s out I’d like the discussion to play out:
The rationale for the contradiciton between “protecting” master and having reviewers give a ship it without review needs some explanation.
The contradiction is important to get people to express their belief. I want people to think “yeah, we could but should we?” In my view, it’s an important element of getting people to think about what they are doing.
In my situation, I have a situation where one person is merging a lot of code to master without review because we are bootstrapping a new implementation. This is making many people on the team nervous, as well it should. We are breaking basic Agile principles (particularly the one about working code) and our working agreement. But are we doing it for a good reason? Possibly. But that’s where the values and principles come in.
My hope is that the team will start to discuss their differences in relation to the working agreement. My hope is that the value conversation will drive better decision making. Decision making like: we should never do this under any circumstance or this situatin is unusual and it’s ok for a while.
Either way, it will be a great opportunity to see how the team’s bought into code review. And we might learn something about the “why” of how we build software together.
I’m hopefull about this dicussion.