Friday, September 10, 2010

Pair Switching Degrades over Time

We had a nice talk today about the natural foot-dragging that is common among pair programmers when it comes time to switch partners.
  1. It's not really social, as in partners gravitating to each other as buddies. Instead it tends to be more work-related. 
  2. It does feel socially awkward to tell your partner you want to go work with someone else now.
  3. It sometimes does happen that partners who are gung-ho agilists will prefer working together. They prefer partners who allow them to do their work well and will improve them over those who create drag by arguing against testing or refactoring.
  4. People get comfortable in a particular task and want to see it through.  This is a good feature usually, and certainly is favorable for people who do individual, non-paired work. In an agile team, it's limiting. Someone needs to move on so that there are more eyes/hands/minds in the code.
  5. If there is no standup there is no pair switching.  If the team relies on assignment from a manager (totally non-agile) then teams tend to complete tasks at different times. This means that no two pairs are finished at the same time, so any switching requires interrupting at least one pair.
  6. Everyone wants to work in the "cool" stuff, but each person has their own definition of "cool."  People will gravitate to tasks in the areas that excite them, and don't want to leave that work to do something else with a different partner.
  7. People are nervous in work that they don't understand well. Rather than eagerly gaining experience in all areas of the app, they try to stay in an area where they have knowledge and leadership. Switching partners may take them into areas they don't understand.
I'd like to open this up to a larger conversation with agile and becoming-agile and surviving-as-non-agilist-on-agile-team people.  Why is it that you don't want to switch three or four times a day?

12 comments:

  1. UnknownSeptember 10, 2010 at 12:57 PM

    On point 5, don't you have the same problem regardless of how work is assigned/picked up by the team?

    ReplyDelete
  2. UnknownSeptember 10, 2010 at 12:58 PM

    Just because we know we should, doesn't mean we will. Like eating right, exercise, etc.. It takes extra discipline, energy and cycles to pair switch. It's just easier to not pair switch.

    ReplyDelete
  3. Jeff LangrSeptember 10, 2010 at 1:21 PM

    It's also harder when you're remote to do much about influencing the issue.

    Every time I face up to these realities of pairing, I tend to think that a stricter set of rules like CARFAX employed might be a good idea for a while.

    ReplyDelete
  4. Brandon CarlsonSeptember 10, 2010 at 1:47 PM

    @Jeff Agreed. Rules are good, and I can't help but to consider Dude's Law in all of this. Simply creating rules may force the issue of pair switching, but it doesn't necessarily provide the value we think. Simply creating and enforcing the rules may not be enough.

    ReplyDelete
  5. AgileotterSeptember 10, 2010 at 2:44 PM

    I'm leary of jumping to mechanics (rules) without going to root causes first. This reverses some of my earlier attitudes.

    I'm hoping we'll get a few more "whys" deep here before positing solutions.

    You can see the "task is too long" and "pair for whole task" issue behind what we've written up there.

    ReplyDelete
  6. Jeff LangrSeptember 10, 2010 at 5:20 PM

    Agreed, I'm not one to jump to rules to solve a problem. But we do need to consider the reasons why we're pairing in the first place, and if perhaps those reasons aren't being met because of the lackluster adherence to pairing.

    Are we getting enough eyes on a given solution? That's one reason to insist on switching mid-task (or mid-story as the case may be). So don't reach for rules, reach instead for things the business insists on that we're not delivering.

    ReplyDelete
  7. j pimmelSeptember 12, 2010 at 2:34 PM

    In my time working with the Energized Work teams we evolved a system of 1/2 day story swapping pair ownership, initially an experiment which stuck because of it's success.

    At the morning standup, pair A (Bob, Jim) took a new story 9.30 the standup and these two would run with it together until the after lunch stand-up.

    At the after lunch stand-up either Bob or Jim would switch out of the pair and take in a new pairing buddy. All the other teams would do the same rotating one out for one in. So for this particular pair, assuming Bob stayed on while Jim moved on, Bob would catch the new pair - Sandra - up on that story's acceptance criteria either completed or underway. Then Sandra would work with Bob for the rest of the day.

    The reason this worked so well for us is that Sandra would then be responsible for carrying that story into day 2, for the first half of the next day now without Bob but with Andy, before she herself would cycle out leaving the story with Andy and a new buddy.

    This model enforced several things that helped us to work around the foot dragging: if a story is owned in rotation, every single participant needs to be switched on, paying attention and engaged.

    You were expected to be able to carry that story forward, speak to it in the scrums, understand new stories in the state you find them when you started working on them, as well as hand them on when you finished with that pairing cycle.

    Since the swaps happened on 1/2 day intervals the amount of catch-up was never huge on every rotation.

    With two very short and to the point stand-ups, this cycled many pairs of eyes over every story, sometimes the same person cycled through the same story a couple of times as it evolved - sometimes deliberately so to allow a senior person to review progress and all - the while exposing team members to a wide range of dev/ops related stories and/or tasks.

    Time outs could be called to request an impromptu swap out of the normal half day cycle, if special expertise might be called upon from a pair who had somehow hit an obstacle.

    You definitely need extra discipline to exercise such an approach, however it brought a heightened sense of exposure to all the in process parts of a development during a sprint, disseminated knowledge rapidly and broadly and worked effectively in stopping pairing degradation.

    ReplyDelete
  8. AgileotterSeptember 15, 2010 at 10:36 AM

    yes, and this is good, but the question is different.

    The question is "Why do we NEED RULES to switch frequently?" or "why the emotional foot-dragging?"

    Let's stop solving, and analyze the problem space for a while. I bet we can find something deeper than rules and practices here. We need to empty our minds of solutions for a little while to do it.

    ReplyDelete
  9. AnonymousSeptember 15, 2010 at 10:58 AM

    1. Why do you expect pairing to be social, rather than work-related?

    2. Why do you feel awkward when I tell you that I want to work with someone else now? What if I say that I want to work on something else now?

    3. Why are people arguing about testing or refactoring while we do the work? Haven't we agreed on how to work by that point, even if just for this session?

    4. Why not let people finish the tasks they're working on? Why do you care so much about finishing a given task?

    5. Why are the only options after completing a task to start another task or wait?

    6. Why don't we let people do what they find interesting?

    7. Why do you feel nervous, as opposed to just a little uncomfortable, working on this you don't know?

    ReplyDelete
  10. jonSeptember 15, 2010 at 12:58 PM

    I am not sure you need explicit rules for switching. While this might be helpful to teach, it won't last.

    Are there natural "positives" that can be better understood, exposed, and celebrated?

    For example, "The team ate better when they lovingly tended the garden, and was warmer because they built a log cabin. The other team that did not do either of these things starved to death that Winter."

    There were no rules posted on the frontier for the pioneers.

    Yeah, point take. A bit harsh of an example :-)

    ReplyDelete
  11. jonSeptember 24, 2010 at 8:14 AM

    Hey! @tenax_technologies spam technical blogs at your peril! Knock it off, please.

    ReplyDelete
  12. AgileotterOctober 1, 2010 at 9:47 AM

    1. Why do you expect pairing to be social, rather than work-related?

    I expected the objections to be, and they're not. This moves us to
    a point where the problem is more solvable.

    ---

    2. Why do you feel awkward when I tell you that I want to work with someone else now? What if I say that I want to work on something else now?

    Not sure.

    ---

    3. Why are people arguing about testing or refactoring while we do the work? Haven't we agreed on how to work by that point, even if just for this session?

    Because they have different base values and haven't soaked up the values yet.

    ---

    4. Why not let people finish the tasks they're working on? Why do you care so much about finishing a given task?

    Because 1) tasks are too large, 2) we want to get things done.

    ---

    5. Why are the only options after completing a task to start another task or wait?

    We have a card for this. :-)

    ---

    6. Why don't we let people do what they find interesting?

    Happily we do, but those things go too long.

    ---

    7. Why do you feel nervous, as opposed to just a little uncomfortable, working on this you don't know?

    This is a point worthy of a lot more reflection.

    ReplyDelete