One big thing that Extreme Programming got right is pair programming. Rather than waiting until work is complete to review code with another developer, the authors of XP figured that if having two pairs of eyes on code was important, why not do it continuously?
At Atomic, we’ve gleaned a lot of value from the practice of pair programming over the years: high-quality code, mentorship, sharing knowledge among team members, and sharing ownership of resulting decisions. Pair programming is one of the most effective modes of collaboration I’ve experienced. So it’s only natural that we look for opportunities to apply that thinking to other tasks.
Why Pair?
One of my triggers to consider pairing on a task is when I see the need to review work on the horizon. Reviews aren’t inherently bad, but pushing feedback to the end of a task can have some downsides.
- It may be too late to incorporate important feedback due to impending presentations or meetings.
- Sunk cost of the work completed may cause teams to avoid the rework needed to arrive at a better solution.
- Review can be frustrating if the person doing the work has to rehash a lot of decisions and tradeoffs.
In my experience, intentionally pairing on work is a much better experience. We get the opportunity to participate in the early generative and later synthesis cycles of the work, and we inherently understand the path to our chosen solution.
So where can we apply this concept? I’ve had success with the following.
1. Pair when writing email.
Let’s start simple. Sometimes having another head in the game when writing an email is extremely helpful. A complex project status update, meeting notes, or a summary of benefits and tradeoffs for a feature implementation are great examples.
Ask the other person to sit down with you and hammer out the message from the start. It feels better than writing the email and feeling nearly done, asking for a second pair of eyes to review, and subsequently rewriting 90% of the message.
2. Pair for functional design.
We want our project teams to have shared ownership over the success of the project, and shared ownership of the functional design of the software is a big aspect of that. Allowing independent thoughts to evolve and grow until a big review point can lead to surprises and dissonance, and neither of those help the team reach that point of shared ownership and buy-in.
Instead, we collaborate early and often through discussions, diagrams, and rough interface sketches. This early collaboration turns late-breaking feedback into generative design work that aligns the team toward a common goal.
3. Pair when breaking down epic stories.
When a story in our team backlog is larger than a certain threshold, we break it down into smaller stories before starting the work. One person could potentially tackle this, but I’ve found that people have different perspectives on which axes to slice across when breaking down work.
In my experience, teams that do this collaboratively have better ownership of the resulting work. They can also deliver the resulting stories incrementally rather than all together when the epic is complete.
4. Pair for estimation.
We love planning poker. It’s a simple way to include a broad team in estimation. In the absence of cards marked with estimate numbers, we use Rock Paper Scissors to throw numbers out as a group. Estimating together is key for developing shared responsibility for meeting timelines and budgets.
5. Pair on expectations and for personal feedback.
At Atomic, we’ve been talking about the concept of radical candor for a while. One of the keys to radical candor is giving timely feedback and not letting problems slide for a long time. In other words, avoid the big review where baskets full of problems come dumping out by having smaller, though perhaps still difficult, conversations and course corrections more frequently.
In conjunction with radical candor, collaboratively defining team norms and expected behaviors sets up a stage where teams can deviate from those norms in a less contentious manner. When you all agree that you want the team to work a certain way, it’s easier to talk about why we’re not doing it and collaborate on resetting norms that work better for the team or getting ourselves back in line.
And More?
We’re continually experimenting with other applications of this thinking. I’d love to hear stories about others’ experiences replacing reviews with collaboration.