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?
- 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.
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