| Newsgroups |
gmane.comp.programming.extreme-programming |
| Message-ID |
<CALaPUVdQX6JAyTTX=4u__sZh=YcxF_g1oBxt4Y3qpaj7v0FdyA@mail.gmail.com> |
One thing that worked well for me was to say that all code checked in by
one person had to be thoroughly code reviewed and accepted by me, but if
you check it in as a pair I automatically accept it. I rejected the
non-paired code about 50% of the time with good comments. Lots of work for
me, but pairing went way up.
On Fri, Oct 14, 2016 at 2:44 PM, Steven Gordon [email protected]
[extremeprogramming] <[email protected]> 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 not recommend such mandates for a co-located team.
>
> On Fri, Oct 14, 2016 at 2:17 PM, George Dinwiddie [email protected]
> [extremeprogramming] <[email protected]> wrote:
>
>>
>>
>> Jay,
>>
>> I'm not sure about the "hold the team to their decisions" part.
>>
>> I worked with an org where the first team I coached, they were told to
>> pair program. They rarely did and when they did, it tended to be the
>> same two people pairing all the time. Retro after retro they decided
>> they had to get better at pairing, but did nothing about it.
>>
>> The next team I coached in the same org, I cautioned against pushing
>> pairing so hard. Instead, we set up the furniture to make pairing easy
>> and let them know we thought pairing was a good idea. They moved in and
>> out of pairing rather fluidly. Sometimes there were 3 people working at
>> one computer. Sometimes there were two people working side-by-side on
>> two parts of the same story, but constantly talking about what they did.
>> At one point the entire team was working closely on one story that had
>> turned out to be more difficult than they had imagined.
>>
>> My learning is to make it easy to do what you think is the right thing,
>> but also make it easy for the team to change their minds. Focus them on
>> the outcomes (and impacts) that are desired. Encourage them to talk
>> about the activities that lead to those outcomes. And be patient.
>>
>> - George
>>
>> On 10/14/16 4:49 PM, Jay Bazuzi [email protected] [extremeprogramming]
>> wrote:
>> >
>> >
>> > "it should ideally be a team decision"
>> >
>> > This is so important.
>> >
>> > Managers, it's up to you to relinquish control over how the team works.
>> > Let the team select a decision-making mechanism (Decider from the Core
>> > Protocols is a reasonable default.) Then hold the team to their
>> > decisions until they decide to change them. Don't undermine their
>> > decisions, even if you disagree with them.
>> >
>> > Warning: If your organization recognizes/rewards performance
>> > individually, this can backfire.
>> >
>> > -J
>>
>> --
>> ----------------------------------------------------------
>> * George Dinwiddie * http://blog.gdinwiddie.com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ----------------------------------------------------------
>>
>>
>
>