New Year’s Resolution: Pairing on Processes

I lost 5 hours of work. file not found Munch scream 300x297 New Years Resolution: Pairing on ProcessesTwas traumatizing. To make matters worse, I realized the work was gone when I was supposed to present it to my team.

Recently, a colleague and I began a project with the intent of optimizing our Bento Box fulfillment process so we could be more responsive to our customers’ needs. At times, I wasn’t even sure what my own process was and I had to spend a substantial amount of time re-outlining my goals every time I revised the data. It’s a process I wanted to create both to use myself and for the benefit of others.

The problem with prototyping autonomously:

  • I act as if I have the answers when I know I don’t;
  • I want the product to be useful for other people, but I’m not sure what “useful” means to others;
  • I’m afraid to show the product to others because I find so many flaws with it myself; I spent more time hacking at the flaws than “building better”;
  • I spent more time making it presentable than making it functional;
  • When I hit a road block there was no one to bounce ideas off of.

Why was I working alone, especially when I already had a designated partner? We advocate for pair customer development, pair designing and pair programming, why then don’t I pair more often?

I ask myself, what is pairing? Kent Beck provides a useful definition:

Pair programming is a dialogue between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

What does pairing look like?

Pair programmers:

  • Keep each other on tasks;
  • Brainstorm refinements to the system;
  • Clarify ideas;
  • Take initiative when their partner is stuck, thus lowering frustration;
  • Hold each other accountable to the team’s practices.

What should I have done instead?

  • I have a partner, I should pair with them;
  • Ask others to share how they would refine the system;
  • Ask others to look at my process and explain what they see and how they’d use it;
  • Ask for partnership when I was frustrated or stuck;
  • Ask others to hold me accountable for incremental goals.

So was my project – 5 hours of work erased by a computer glitch – a waste?

My work was lost, but my effort was not. The project I owned was a waste, but the project that belongs to our team has been improved by this learning experience. If I had brought a completed “perfect process” to the team, it might never have been implemented because a process imposed is rarely accepted.

Instead, I’m thinking of my effort as a prototype because as Kent Beck says…

Pairing doesn’t mean that you can’t think alone…You can even prototype alone and still respect pairing. However, this is not an excuse to act outside the team. When you’re done exploring, bring the resulting idea, not the code, back to the team. The results will be more widely understood benefitting the project overall.

photo 1 300x225 New Years Resolution: Pairing on Processes

My next task is to reuse my effort and pair with my partners and redo the process. I’m sending a calendar invite as we speak…

This is one of our New Year’s Resolutions as a company: Pair. Pair often. Pair in rotation.

P.S.: This post was pair blogged by Jeana Alayaay and Tristan Kromer

One Thought on “New Year’s Resolution: Pairing on Processes”

  1. Daniël W. Crompton

    Usually while working I have a goal which I need to achieve, and usually I try to take the shortest route, even when the shortest route means that I will end up doing more work tomorrow. So losing my work means that I have a primer in what the solution could be. So I can go from A to B to C and know what B is going to look like and know what corners I can cut.

    One of my favorite things to do when I’ve written Proof of Concept code is to delete it, the idea is usually excellent – the code is not so good.


Leave a Reply

XHTML: You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>