Sorry, an error occurred while loading the content.
Browse Groups

• ## Re: [XP] How to swap pairs among tasks

(8)
• NextPrevious
• ... We have a rule that no task should be longer than 3 days, or must be split. But I think lower bounds and smaller tasks would be even better, if you can
Message 1 of 8 , May 1, 2003
View Source
On Thu, May 01, 2003 at 02:41:58PM -0000, oonkean wrote:

> When a story is broken into tasks , is there a recommended size for
> a task (e.g should be finishable in less than a day) ?

We have a rule that no task should be longer than 3 days, or must be
split. But I think lower bounds and smaller tasks would be even better, if
you can manage it.

> How long should a pair stick together ? My understanding is that a
> pair should work on a task , and after completing the tasks change
> pairs.

We have developers sign up for tasks, not pairs. One person is responsible
for the continuity of the tasks, and can change pairs halfway through
completion of a task.

In fact, we encourage multiple pairing combinations to work on one task,
to get the maximum different inputs from people and also to stir the new
knowledge throughout the team. If the tasks were smaller, having only one
pair work on it would be less of an issue.

> How can
> we handle this situation then ? By pairing for the whole day and
> swap the next day ? In this case , how do we handle unfinished
> previous day's tasks ?

This is what we did. People with tasks against their names get new blood
and the new pair continues working on the task.

> Assuming task A and task B are related , and programmer 1 and
> programmer 2 are working on task A. When task A is finished , it is
> time to swap pairs. Since task B is related to task A , should
> either programmer 1 or programmer 2 continue to work on task B with
> a new pair partner ?

If you rotated pairs frequently, most of the team would be familiar with
task A, and almost anyone could work on task B. We would rather have
programmer 1 and programmer 2 working on part of A, and then programmer 1
and programmer 3 working on the rest of A, and then programmer 2 and
programmer 4 working on B. (Note that this also solves your question 4).

We try to avoid what you describe, else you get code-ownership issues.
Programmer 1 builds a whole infrastructure and little empire for solving
task A and task B. Other members of the team have valuable contributions
and insights to how it should be done, but programmer 1, by virtue of
"owning" task A and task B excercises subtle control to ensure it gets
done "his way".

--
,_
/_) /| /
/ i e t e r / |/ a g e l
http://www.nagel.co.za
• ... I recommend keeping them under a day. Sometimes a task might take longer, but I d usually look for ways to spin off part of the task for another pair to
Message 1 of 8 , May 1, 2003
View Source
--- In extremeprogramming@yahoogroups.com, "oonkean" <oonkean@y...>
wrote:
> Question 1:
> -----------
> When a story is broken into tasks , is there a recommended size for
> a task (e.g should be finishable in less than a day) ?

I recommend keeping them under a day. Sometimes a task might take
longer, but I'd usually look for ways to spin off part of the task
for another pair to do.

>
> Question 2:
> -----------
> How long should a pair stick together ? My understanding is that a
> pair should work on a task , and after completing the tasks change
> pairs. I read somewhere in the posts mentioning synchronization
> problems between pairs (e.g pairs have finished , but all other are
> still in their tasks , therefore there are no pair to swap). How
can
> we handle this situation then ? By pairing for the whole day and
> swap the next day ? In this case , how do we handle unfinished
> previous day's tasks ?

(I did have a recent message on this but it's too painful to find it.)

Basically, if you're going to swap when tasks are complete, the
only "natural" time is at the start of the iteration. (Because when
else will two pairs finish at the same time?) (One pair for an
iteration isn't enough swapping in my book.)

To keep the swapping going, the next natural swap point is at the
beginning of the day and possibly after lunch.

The next natural swap point is when a pair finishes a task. It's kind
of hard to do this, because it means that even though one pair's
done, the other is in the middle of the task. I like to see swaps at
least this often, to keep everybody aware of what others are doing.

But that would only affect four people; we might like everybody
swapping more...

So, I've worked with a team that has a timer, and has set it to go
off every hour. When the timer rings, they swap pairs and reset the
timer. (**To me, a disciplined thing like this is something I would
never expect to assign to a team, they have to value & sustain it
themselves.**)

At first, it takes getting used to because you feel interrupted. And
I expect some people miss the ownership sensation. But it does have
good side effects:
- it encourages some detachment about the task (so we have little of
people "not letting go" when fresh eyes are needed).
- it makes the partner pay better attention (as they may have to
explain it to someone else an hour from now)
- it makes for faster cross-training
- it lets more of the task be parallelized - at swap time, we might
add a new task to the list and let two pairs continue what one
started.

> Question 3:
> -----------
> Assuming task A and task B are related , and programmer 1 and
> programmer 2 are working on task A. When task A is finished , it is
> time to swap pairs. Since task B is related to task A , should
> either programmer 1 or programmer 2 continue to work on task B with
> a new pair partner ? In such cases , programmer 1 (or 2) would need
> to brief the new partner on what happened in task A so that the new
> partner can catch up. Is this the way pairing for tasks works ? I
am
> still trying to reconcile this with XP's principle of allowing
> programmers the right to sign up for their own tasks.

Different teams do it differently. Some have pure task ownership by
the individual, in which case either that individual is working on
it, or nobody is. Others give it to pairs.

The team I described above puts the initials of the pair by the task;
when a different pair takes over, they adjust it. (So you own it only
while you're working on it.) At swap time, the person who wants it
most keeps it.

But yes, in any case, it's common to brief a new partner when you
swap pairs.

(And I wouldn't insist than an "A" works with a "B" on the rest of
the B task in the situation you describe.)

>
> Question 4:
> -----------
> Following question 3, can we actually allow a new pair to work with
> task B ? If we allow , how can the new pair catch up with what
> happened in Task A ? By poking around the code , or by having a
> session meeting up with programmer 1 (or 2) to clarify the tasks ?
> Would this not take up substantial amount of programmer 1 (or 2)'s
> time to ? So potentially , it could be the case where everyone is
> briefing everyone else details about what they did yesterday. I
> understand that the stand up meeting is not the place to talk about
> this , hence daily there will seem to be an extra time involved in
> this sort of briefing ?

It's practically always the case that one of the pair keeps the task
at swap time. (The exception would be where the task was so simple it
needs almost no explanation.)

This is a place I find the frequent swapping helps. If you've worked
with several different people yesterday, you'll have seen more of the
system and require less explanation to make progress.

>
> I have not done nor manage pairing before , and will be
implementing
> this soon in my team. I am trying to visualize how it works.As you
> can see , I am pretty foggy about how this thing should work !

Laurie Williams' book, Pair Programming Illuminated, would be a good

It's an area people can be nervous about.

I've become willing to be much more fluid than I ever expected to be

My starting point is to ask people to swap at least a couple times a
day, and make an effort to swap when they complete a task. (I've
grown used to the clocked approach, but I would probably only try it
as "let's do a one-day experiment to get a feeling for what swapping
is like".) (William Blake - no relation - "You never know what is
enough unless you know what is more than enough.")

>
> Thanks a lot for reading this.
> Kean
Good luck!

-- Bill Wake
• ... Shorter is probably better. If everyone can work so as to release code twice a day, that s pretty good. But I would prefer to do an actual slice of a
Message 1 of 8 , May 1, 2003
View Source
On Thursday, May 1, 2003, at 10:41:58 AM, oonkean wrote:

> Question 1:
> -----------
> When a story is broken into tasks , is there a recommended size for
> a task (e.g should be finishable in less than a day) ?

Shorter is probably better. If everyone can work so as to release code
twice a day, that's pretty good.

But I would prefer to do an actual slice of a /story/ in that time, rather

I'm leaning now more and more toward breaking down stories into smaller
stories, and not thinking so much about tasks.

> Question 2:
> -----------
> How long should a pair stick together ? My understanding is that a
> pair should work on a task , and after completing the tasks change
> pairs.

That's probably ideal. Bill Wake's ideas should be considered. Did he
mention that other teams are doing pair-swapping by the clock as well?

> I read somewhere in the posts mentioning synchronization
> problems between pairs (e.g pairs have finished , but all other are
> still in their tasks , therefore there are no pair to swap). How can
> we handle this situation then ? By pairing for the whole day and
> swap the next day ?

Try just swapping. More swapping may be awkward for a while but I bet
you'll see benefits.

> In this case , how do we handle unfinished
> previous day's tasks ?

Throw them away and do them tomorrow? I am serious.

> Question 3:
> -----------
> Assuming task A and task B are related , and programmer 1 and
> programmer 2 are working on task A. When task A is finished , it is
> time to swap pairs. Since task B is related to task A , should
> either programmer 1 or programmer 2 continue to work on task B with
> a new pair partner ? In such cases , programmer 1 (or 2) would need
> to brief the new partner on what happened in task A so that the new
> partner can catch up. Is this the way pairing for tasks works ? I am
> still trying to reconcile this with XP's principle of allowing
> programmers the right to sign up for their own tasks.

Sounds right to me, if I understand what you're saying.

> Question 4:
> -----------
> Following question 3, can we actually allow a new pair to work with
> task B ? If we allow , how can the new pair catch up with what
> happened in Task A ?

I would try never to hand off partial code to a whole new pair.

> By poking around the code , or by having a
> session meeting up with programmer 1 (or 2) to clarify the tasks ?

If I had to, this is what I would do. But pairing with one of them is
better. I'd try not to do the handoff.

> Would this not take up substantial amount of programmer 1 (or 2)'s
> time to ? So potentially , it could be the case where everyone is
> briefing everyone else details about what they did yesterday. I
> understand that the stand up meeting is not the place to talk about
> this , hence daily there will seem to be an extra time involved in
> this sort of briefing ?

Briefing is not an XP practice. There might be quick design sessions.
Mostly, though, lots of pairing will quite likely work best.

> I have not done nor manage pairing before , and will be implementing
> this soon in my team. I am trying to visualize how it works.As you
> can see , I am pretty foggy about how this thing should work !

Try it, tweak it. Do lots of pairing. Get good at it. You'll figure it out!

> Thanks a lot for reading this.

Thanks for writing it!

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting. --Karl Wallenda
• ... size for ... release code ... time, rather ... smaller ... I like that! Breaking stories down into tasks is effectively making design decisions. I want to
Message 1 of 8 , May 1, 2003
View Source
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<ronjeffries@a...> wrote:
> On Thursday, May 1, 2003, at 10:41:58 AM, oonkean wrote:
>
> > Question 1:
> > -----------
> > When a story is broken into tasks , is there a recommended
size for
> > a task (e.g should be finishable in less than a day) ?
>
> Shorter is probably better. If everyone can work so as to
release code
> twice a day, that's pretty good.
>
> But I would prefer to do an actual slice of a /story/ in that
time, rather
> than just tasks.
>
> I'm leaning now more and more toward breaking down stories into
smaller
> stories, and not thinking so much about tasks.

I like that! Breaking stories down into tasks is effectively
making design decisions. I want to push design decisions closer
to the code and TDD.

When you talk about doing a /slice/ of a story, I assume that you
are referring to a chunk of work that can be integrated. (Is that
right?) If so, one might say that you are breaking down the story
into tasks, but only as you discover each task by doing it!

I've always been into small stories (even though I've done the
task thing). I long ago noted that my idea of story size was
small compared to what I was reading. XP Installed says, "stories
should encompass a week or two of programmer time", but those
always struck me as /big/. But I'm under the impression that the
"standard" story size has been getting smaller. What size are you
currently tending towards?

Kiel Hodges
SelfSo Software

> Ron Jeffries
> www.XProgramming.com
> To be on the wire is life. The rest is waiting. --Karl Wallenda
• ... Four hours. Ron Jeffries www.XProgramming.com Hope is not a strategy. -- Michael Henos
Message 1 of 8 , May 1, 2003
View Source
On Thursday, May 1, 2003, at 9:28:58 PM, Kiel Hodges wrote:

> I've always been into small stories (even though I've done the
> task thing). I long ago noted that my idea of story size was
> small compared to what I was reading. XP Installed says, "stories
> should encompass a week or two of programmer time", but those
> always struck me as /big/. But I'm under the impression that the
> "standard" story size has been getting smaller. What size are you
> currently tending towards?

Four hours.

Ron Jeffries
www.XProgramming.com
Hope is not a strategy. -- Michael Henos
• ... I think that s exactly the message that I read .. I had a feeling it was written by you , Bill. Thanks Kiel , Ron (both of you for the second time helping
Message 1 of 8 , May 2, 2003
View Source
> (I did have a recent message on this but it's too painful to find
>it.)

I think that's exactly the message that I read .. I had a feeling it
was written by you , Bill.

Thanks Kiel , Ron (both of you for the second time helping me out),
Bill and Pieter for you thoughts. Now I understand the various ways
pairings work. I thought for a while that there are some magical
scheduling techniques to it .. apparently the team will need to
adapt to this form of working.

Well , I have only one shot at implementing XP in my organization.
Hope I can get some results to show to both management and the
developers that XP is the way to go. I can't imagine working any
other way. I have not done XP before , and the organization can't
afford a coach. Your feedback on my questions have been helpful. And
yes , I will get myself the pair programming book by Laurie
Williams. Thanks for pointing me the way. Courage !

Kean
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.