Working Agreements

Within my company, we're talking about agreements and expectations a lot.

Safety in decision-making and action-taking is all caught up in expectations and working agreements, and many of ours have been unspoken, unwritten, and un-negotiated. As a result, it is easy to drop things, expecting others to pick them up when they don't know to do it. It's also to do things that seem to step on your colleague's toes or which work at cross-purposes. 

I was doing some work for a very dear client of ours, and I needed to revisit the Debian New Package Maintainer's guide. What appears on page one? A set of working agreements.

• We all are volunteers.
  
  • You cannot impose on others what to do.
  • You should be motivated to do things by yourself.
• Friendly cooperation is the driving force.
  
  • Your contribution should not overstrain others.
  • Your contribution is valuable only when others appreciate it.
• Debian is not your school where you get automatic attention of teachers.
  
  • You should be able to learn many things by yourself.
  • Attention from other volunteers is a very scarce resource.
• Debian is constantly improving.
  
  • You are expected to make high quality packages.
  • You should adapt yourself to change.

This is actually a pretty good set of working agreements for any project, church, or even commercial team.

We are all volunteers, if we could go elsewhere and do something else. Therefore, imposing on others or not doing things you can manage on your own is inconsiderate of others.

Friendly cooperation is the basis of any team, whether they consider themselves volunteers or not.

Likewise, constant improvement is the law of the land in any software project. We should be flexible to adopt any improvements that come our way -- even going so far as to radically change our programming habits (see TDD, Refactoring, Code Smells, Pair Programming... )

The item about not being a school is probably the only area where Debian guidelines and team software development team part ways. A good team is a highly effective school, or it's not really a great team. The learning is a key part of the landscape.

Face it, if you program today exactly like you did three years ago, you've wasted three years. There is no shortage of useful skills to add to our repertoire.

When we pair program or mob program, we have ready teachers. We need all the information we can get to make decisions quickly (enough)  and well (enough). We lean on each other more, but that includes being someone others can lean on.

The Interplay of Failure, Learning, and Options

We talk about failures a lot.

Fail Fast!
Safe to Fail!
Learn from Failure!

One would think that  people hire us to screw things up. Why the fascination with failures? Why not talk about successes?

Admittedly, the dialog is off-base a bit. We're not really keen on failure at all. We don't like to be wrong, and would hesitate to ship a product if we knew it was the wrong thing to build, or it was built in the wrong way.

There are problems that can be solved without error by one person who thinks about them for a little while and types in the code that solves the problem.  The term for this kind of problem is uninteresting problems. These problems are smaller than one brain, or else the solution is already well-known. We tend to either shuffle this problems off on the noobies, or else we scribble down the answer and move on without any real sense of accomplishment.

Any problem that is interesting will involve experimentation and learning. Those problems cycle on steps like these:

• Try (do your best)
• Fail (intentionally try the stuff you're not sure about)
• Investigate (find out what you didn't know)
• Learn (incorporate new knowledge)
• Exercise options: pivot, persevere, abandon, expand

It's not really the failing we value; it's the opportunity for learning and the chance to exercise options.

Pivot is a kind of success because we choose a different path, one that has greater promise. It may mean abandoning some part of our design, or rethinking our user stories, or even throwing out a bit of the architecture. It might mean accruing more design, more feature descriptions, more architecture. Either way, it's a more informed decision that we would have made before the failure. Better now than later!

Abandon means that we have succeeded in saving money and time because we learn which problem is not actually worth solving, or the solutions to the problem are too expensive to bother investing in.  Again, better to get that out of the way before we suck down too much time and money!

Persevere is what we do when we learn that our current direction has promise, or that nothing else looks more promising.  It's what people traditionally consider "success."

Expand is what happens when we know we have a great idea, and that we can leverage it in ways we hadn't expected. It may mean that we pivot in our feature descriptions or technical design to take advantage of new learning. Expanding a great idea can lead to innovations (each of which has its own try/fail/learn/... cycle).

If we don't fail early enough, then our options begin to expire. We may no longer have the choice of expanding in a promising direction, shutting down expensive time-wasting ideas, etc. In short, we have no choice but to hunker down, work harder, and hope that it comes out okay.

Too many people do the 'easy stuff' first -- the stuff that they definitely feel that they know how to do. That leaves all the risky stuff for later, when you are up against the 11th hour of the deadline and you aren't sure how to recover.

When we say we value "Failing Fast" we put the emphasis on the second word, not the first.

The new project...

It's been quiet on the blog lately, but not at home.

My nine-year-old nephew has come to spend a year with us, to take advantage of Libby's skill as a home schooler. He's also getting a crash course in family dynamics and nutrition.

This new project is just barely "off the ground" right now, as this was our first week together. It takes a fair amount of our attention as a group. I'm always split between professional and personal goings-on here, and Libby is 100% committed to helping James get oriented and to internalize the way things work here.

He's a good kid. Very outgoing, very talkative and very creative. He's further along academically than we were led to believe, and really likes adventures. He's a little less keen on adventures in nutrition, responsibility, and endurance in chores and projects. Sometimes the innerspace is harder to experience and explore than the external experiences.

He is looking forward to his first snowfall. We are too.

If things get quiet here, it's because they're not so quiet in the Otter house. It's a busy time.