| Newsgroups |
gmane.comp.programming.extreme-programming |
| Message-ID |
<CALaPUVd6WBWM+28H7aFkZNK2_nF+XuFV3MPRrekPyT53Y56Lcw@mail.gmail.com> |
P.S. that was on a 100% remote team.
On Fri, Oct 14, 2016 at 3:13 PM, Adam Sroka <[email protected]> wrote:
> 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
>>> ----------------------------------------------------------
>>>
>>>
>>
>>
>
>