Re: Any advice on remote pairing?
| Newsgroups | gmane.comp.programming.extreme-programming |
|---|---|
| Message-ID | <CALaPUVcPCV5bwcXjdiuNOGZFwqFEwmc_6sPBz4pXH1ovf8OXOw@mail.gmail.com> |
On Fri, Oct 14, 2016 at 3:21 PM, Steven Gordon [email protected] [extremeprogramming] <[email protected]> wrote: > > > > > On Fri, Oct 14, 2016 at 3:14 PM, George Dinwiddie [email protected] > [extremeprogramming] <[email protected]> wrote: > >> >> >> Steven, >> >> On 10/14/16 5:44 PM, Steven Gordon [email protected] >> [extremeprogramming] wrote: >> > >> > >> > These examples of a team deciding for themselves whether and when to >> > pair are all co-located. >> > >> > The original question is about remote pairing for a fully distributed >> > team. I can see mandating pairing (as well as the other XP practices) >> > as a prerequisite for taking the risk of investing in a fully >> > distributed team. >> >> I would rather see making it easy to pair at will, and easy to find >> others ready to pair at the moment. Mandating pairing will especially >> backfire in remote work when the propagation delay is getting in the >> way. Nobody likes to be told to do something that's preventing them from >> getting their work done. >> >> - George >> >> How would you make pairing "easy" for a fully distributed team? > > There are things you can do to make it relatively less hard. For example, you can structure your time in such a way that it is clear when pairs will be available and when they won’t be. You couple this with a promise not to work on production code without a pair. I prefer to use most of this time studying the stuff I think I’ll need to know for the next pairing session so that I don’t have to look it up then. This is very effective for me, but it is very hard to institute unless you are starting from scratch.