Re: Any advice on remote pairing?

On Sat, Oct 15, 2016 at 10:28 AM, Jay Bazuzi [email protected]
[extremeprogramming] <[email protected]> wrote:

>
>
> In the cases I'm thinking of, the team liked the decision but the org did
> not (or the team sensed that the org did not).
>
> For example: team decides to try full-time pair programming. They enjoy it
> a lot. The org asks that each feature or component or bug has an owner, so
> they "know who to go to with questions about that thing". When we pair on
> "your" thing, you worry that people will think you're cheating by getting
> me to do "your" work, and I worry that I'm letting "my" thing be ignored
> which will be seen as bad. So we are slow to actually engage in pairing,
> even though we A) decided to pair, and B) enjoy pairing.
>
>
Yeah, that won’t work, but it’s easy to fix. You need collective ownership
for pairing to work well. If the business insisted on having an owner I
would make it myself, as team lead, for everything. If they have a question
I’m the one. If you don’t have a team lead, maybe you have a scrum master
or coach. Running interference on this sort of thing is part of their job
description.


> The "enforcement" I'm thinking of is reminding the team "you decided you
> wanted to do X. To me it looks like you're not doing that right now. Do you
> still want to do it, or revisit that decision?" The team is free to change
> their decisions as they see fit.
>
>
That’s what retrospectives are for. You can discuss the commitment to
pairing, the root cause of not pairing, and what you want to do about it.