Agile Love

July 28, 2013
Part 1 of a 3 part series on human relationships.

One of the most useful things that being a programmer has taught me is how to spot isomorphisms. Roughly speaking, two problems are isomorphic if you can transform one into another, and then back again without losing anything in the process. Isomorphisms are helpful because they allow us to solve problems that we don’t know how to solve by transmuting them into ones we do. This is exceptionally powerful.

I am constantly surprised by life. I consider this to be a good thing. Every morning at my place of gainful employment (where I work as a software engineer) everyone on the team huddles into a too-small office for ten minutes where we go around in a circle and talk about what we did the day previous, and what our plans for that day are. This meeting is known as a scrum and it is an integral part of the agile methodology of software development.

The general idea behind agile is to be able to quickly iterate on an design and get as much feedback as possible, in an attempt to ensure the stakeholders are happy throughout the entire process. All in all, it’s considered a good practice throughout the industry.

Anyway, I was saying that I was surprised by life. I was surprised by life the day I realized that these scrums were actually useful, even on days when we were all pretty sure nobody had anything to talk about. On days like those it’s important to know that everybody is waiting on an external dependency, or that morale is low, or what have you.

Having a regular block of time dedicated to keeping everyone in the loop and solving problems before they bite you is actually a really good idea, when you think about it.

Why is it a good idea?

You probably have a gut understanding that this is a good idea, but please bear with me while I excruciatingly spell it out. I’ve got a point, I promise. Reasons this is a good idea:

  • Potential problems are mentioned before they turn into actual problems, and the entire team can brainstorm on ways of fixing them.
  • The entire team gets a better understanding of the project scope, not just those domains they’re directly involved with.
  • Furthermore, everyone gets an idea of what their coworkers’ day-to-day job is like.
  • Feedback becomes frequent, reliable and near-instant.

The astute reader will notice that these reasons don’t mention software engineering whatsoever. In fact, they seem to be applicable anywhere that people are working on individial shards of a larger whole. If our analysis is correct, agile methodologies can be beneficially applied in any productive and co-operative setting.

Relationships seem like an obvious choice of such.

I’ve started implementing this policy throughout my entire love life, and the results are startling. It’s an easy hack to foster deeper levels of trust, head off problems at the pass, and ensure that everyone is committed to collective improvement.

SGSBHDIIT, or Sounds Good Sandy, But How Do I Impliment This?

First things first: posit the idea to your partner(s). Convince them and yourself that this has the potential of being useful.

Like always, precommitment is a good idea. Set aside a regular block of time with each person to do this. Once a week is a good amount of time to start with; you can always tweak the process later. Make sure all parties involved put the event on their calendar.

Before getting together for your meeting, as individuals, compile a list of particular things that worked well in the last week of the relationship, and particular things that didn’t. Everyone should bring these lists to the meeting and precommit to bringing up every point. Come in with no fewer than five points in each category.

At the beginning of each session, each participant should declare crocker’s rules in effect. By declaring crocker’s rules, the individual is revoking their right to be emotionally upset by anything said in the meeting. This helps to create a zone in which constructive criticism is welcomed and ensures that the discourse is as honest as possible. These are good things. Trust your partner(s). If you don’t consider finding one(s) you do.

After all parties have brought up every point on their lists of good and bad things, the collective should brainstorm on ways to make the relationship better. The focus here should be “now that we know what works well and what doesn’t, what can we do with this knowledge?”.

And really, that’s it. Easy! That’s all there is to it. You might be amazed at the things you’ll learn about your partner(s) through this process. I can guarantee there are small annoyances that you create all the time but which are too minute to make a fuss over. Having an explicit model of communication helps alleviate this problem by batching tiny problems together.

It might sound silly, but give it a try. (I find myself writing that disclaimer often - maybe it should be the name of my blog!). You’ve got nothing to lose, and improvement is impossible without first changing.