Agile in a Flash 32

When Not Pairing – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #32)

> Build nonproduction code(8)

> Create meaningful and lasting documentation

> Work on spikes for future stories

> Learn a new tool or technique

> Identify production code needing refactoring

> Refactor tests

> Improve existing test coverage

-8. Test frameworks, tools, the build, and so on

--

It’s not always possible to pair, even in shops where pairing is standard practice. Realities such as variant working hours and odd numbers of programmers make full-time pairing difficult. For these reasons alone, it’s probably a bad idea for your team (or worse, someone outside the team) to mandate 100 percent pairing on everything.

Card 30, ABCs of Pair Programming, clearly defines when you must pair: when developing any production code. Refer to the other side of this card for a list of what you might do, other than twiddle your thumbs, when no pair partner is available.

Your team should derive ground rules for work done during pair-less times. Start with this list. Sometimes, unfortunately, you’ll need to change production code, but let that happen only rarely. Your team should derive ground rules for this circumstance. Since the primary goal of pairing is review, some form of follow-up review is the most sensible place to start.

--Opportunities to improve environements