headers
drc | 2 Dec 2009 01:57
Favicon
Gravatar

Fw: if you could post this iPhone developer "ad" appropriately, I'd be grateful


Hey folks,

Friend of mine is looking for a good iPhone developer.  Pointers
appreciated.

Thanks,

-- David Chilcott
Outformations, Inc.

Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the
Mystery.
---------------------------------------------------------------------------
Email: drc <at> outformations.com
Voice: 510.655.7122
Skype: DavidChilcott
Twitter: DavidChilcott
Facebook: www.facebook.com/DavidRChilcott
LinkedIn: www.linkedin.com/in/DavidChilcott
----------------------------------------------------------------------------

Ask me about the Outformations Agile Enterprise JumpStart
http://bit.ly/AgileJumpStart
----------------------------------------------------------------------------

Hi David,

Apropos our conversation last week, if you could post this in appropriate
fora that you have access to, that would be greatly appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Troy Frever | 2 Dec 2009 02:35
Picon
Favicon

AONW 2010 volunteers needed

Hello,

My name is Troy Frever, and I'm the Event Coordinator for Agile Open
Northwest 2010 (see http://www.agileopennorthwest.org for details.) A formal
announcement of this year's event will be out shortly, but in the meantime I
am recruiting for a couple of volunteers. As you are probably aware, this
will be the 4th year of Agile Open Northwest, and the 2nd in Seattle (we
alternate between Portland and Seattle.) This is a small, local,
inexpensive, and generally awesome Open Space/Agile conference that has been
extremely well-received in recent years, and we are currently preparing for
another successful event on February 9th and 10th, 2010, at Seattle Center.

I need two volunteers to help with particular aspects of site logistics,
both before and during the event. If you would like to give a little back to
the local agile community while also getting to know and work with some
Puget Sound agilistas, please contact me directly at troyf <at> pobox.com.

Thanks, and hope to see you at AONW 2010 in February!

Troy Frever

[Non-text portions of this message have been removed]
Permalink | Reply | 0 comments |
headers
pncampbell99 | 2 Dec 2009 13:22
Picon

Re: "Cards" (was: summary of the discusion


--- In extremeprogramming <at> yahoogroups.com, Sean Corfield <seancorfield <at> ...> wrote:
>
> On Fri, Nov 6, 2009 at 3:31 AM, Phlip <phlip2005 <at> ...> wrote:
> > For example, when we say "story card", we don't mean a userstory written into a
> > computer program with a "card" object. We mean a real, paper, 3x5 index card. A
> > team should start by writing these cards and pinning them to a cork board. Only
> > after trying that for a while should a team then experiment with an automated
> > card system, such as Mingle, to determine if the card system adds any value.
> 
> I see quite a bit of emphasis on physical cards for stories, at least
> at first (as a learning tool to get people used to the concept).
> 
> Can some folks talk about why putting the stories into some shared
> data store rather on physical cards might not be advisable? What sort
> of problems have folks run into using some simple electronic
> representation, such as a spreadsheet or some other simple electronic
> document / set of documents?
> -- 
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

Its hard to come up with a scientific explanation but the experience of myself and others that have tried
"electronisising" xp is that its counter productive.

Its worth noting that the same applies to most of the xp practices. But thats the essence of xp - its a set of
(Continue reading)

Permalink | Reply | 1 comment |
headers
zdnfa | 2 Dec 2009 16:56
Picon
Favicon

balancing the pair in pair programming


Dear all,

One of the issue I have come thru is how to make up pairs. I mean how do we for the pairs at the very beginning of
the project. In one of the articles I have come thru says that pairs could be formed in one of three
compositions: expert-expert, expert-naive, and naive-naive.

In fact -as I think- one cannot make sure that is easy to find the first combination in all cases and contexts.
Yet, do we face a case where the two expert may face some competetion? will this competetion be counterproductive?

in the other case will a naive partner be a problem to his/her expert parnter?

I would like to hear from you

Regards

Zaidoun
Permalink | Reply | 13 comments |
headers
George Dinwiddie | 2 Dec 2009 18:20
Favicon

Re: balancing the pair in pair programming

zdnfa wrote:
> Dear all,
> 
> One of the issue I have come thru is how to make up pairs. I mean how
> do we for the pairs at the very beginning of the project. In one of
> the articles I have come thru says that pairs could be formed in one
> of three compositions: expert-expert, expert-naive, and naive-naive.
> 
> In fact -as I think- one cannot make sure that is easy to find the
> first combination in all cases and contexts. Yet, do we face a case
> where the two expert may face some competetion? will this competetion
> be counterproductive?
> 
> in the other case will a naive partner be a problem to his/her expert
> parnter?

In my experience, if two people are willing to work together 
collaboratively, then they can do so productively no matter what the 
skill levels of the two.  Of course, the expert-expert pairing is likely 
to be more productive than the naive-naive pair, but even that's not 
always true.  Often the expert-naive pairing is the richest, as the two 
people pairing may have a wider range of viewpoints and assumptions.

In any case, I would not advise "making the pairs" but let them make 
themselves.  And I would advise having them switch pairing partners 
frequently.  These two behaviors will tend to make the whole process 
more fruitful and robust.

  - George
(Continue reading)

Permalink | Reply | 7 comments |
headers
JackM | 2 Dec 2009 18:30

Re: balancing the pair in pair programming

I also think that expert-junior pair is a good way to educate and bring the skill level of the junior up

jack
www.agilebuddy.com
twitter.com/agilebuddy
blog.agilebuddy.com

--- In extremeprogramming <at> yahoogroups.com, George Dinwiddie <lists <at> ...> wrote:
>
> zdnfa wrote:
> > Dear all,
> > 
> > One of the issue I have come thru is how to make up pairs. I mean how
> > do we for the pairs at the very beginning of the project. In one of
> > the articles I have come thru says that pairs could be formed in one
> > of three compositions: expert-expert, expert-naive, and naive-naive.
> > 
> > In fact -as I think- one cannot make sure that is easy to find the
> > first combination in all cases and contexts. Yet, do we face a case
> > where the two expert may face some competetion? will this competetion
> > be counterproductive?
> > 
> > in the other case will a naive partner be a problem to his/her expert
> > parnter?
> 
> In my experience, if two people are willing to work together 
> collaboratively, then they can do so productively no matter what the 
> skill levels of the two.  Of course, the expert-expert pairing is likely 
> to be more productive than the naive-naive pair, but even that's not 
> always true.  Often the expert-naive pairing is the richest, as the two
(Continue reading)

Permalink | Reply | 4 comments |
headers
D'Arcy J.M. Cain | 2 Dec 2009 18:45
Gravatar

Re: balancing the pair in pair programming

On Wed, 02 Dec 2009 17:30:22 -0000
"JackM" <jack <at> brightspark3.com> wrote:
> I also think that expert-junior pair is a good way to educate and bring the skill level of the junior up

Not just the junior.

--

-- 
D'Arcy J.M. Cain <darcy <at> druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.
Permalink | Reply | 0 comments |
headers
Dave Smith | 2 Dec 2009 18:53
Picon
Gravatar

Re: balancing the pair in pair programming

On Wed, Dec 2, 2009 at 9:30 AM, JackM <jack <at> brightspark3.com> wrote:

> I also think that expert-junior pair is a good way to educate and bring the
> skill level of the junior up
>

It works both ways. I'm often the expert/senior half of the pair, and yet
seldom come away
from a pairing session without having learned something. It might be a new
keyboard trick, or a
non-obvious way to pull off a refactoring, or an insight about how to
articulate a design principle.

Dave

[Non-text portions of this message have been removed]
Permalink | Reply | 2 comments |
headers
Adam Sroka | 2 Dec 2009 18:55
Picon
Gravatar

Re: balancing the pair in pair programming

Stereotyping the way that pairs interact based on experience can be useful
for research purposes, but it is inherently limiting. There is really only
one type of pair: human-human. Each such pairing is entirely unique, and so
long as both are willing and able to collaborate there is value.

Choosing who will pair is limiting, because it precludes collaborations you
haven't imagined yet.

Switching pairs more frequently leads to a large variety of rich
collaborations even for a very small team, and research has established that
it leads to higher throughput and greater quality.

On Wed, Dec 2, 2009 at 7:56 AM, zdnfa <zdnfa <at> yahoo.com> wrote:

>
>
>
> Dear all,
>
> One of the issue I have come thru is how to make up pairs. I mean how do we
> for the pairs at the very beginning of the project. In one of the articles I
> have come thru says that pairs could be formed in one of three compositions:
> expert-expert, expert-naive, and naive-naive.
>
> In fact -as I think- one cannot make sure that is easy to find the first
> combination in all cases and contexts. Yet, do we face a case where the two
> expert may face some competetion? will this competetion be
> counterproductive?
>
> in the other case will a naive partner be a problem to his/her expert
(Continue reading)

Permalink | Reply | 0 comments |
headers
D. André Dhondt | 2 Dec 2009 18:53
Picon

Re: balancing the pair in pair programming

On Wed, Dec 2, 2009 at 4:56 PM, zdnfa <zdnfa <at> yahoo.com> wrote:

> One of the issue I have come thru is how to make up pairs. I mean how do we
> for the pairs

Since pairs will probably swap out 2+ times per day, don't sweat the
decision on who should pair with who.  Focus on finding a way to make
meaningful progress, then let the next pair re-evaluate where the code
should go next.

Yet, do we face a case where the two expert may face some competetion? will
> this competetion be counterproductive?
>
> Competition of ideas is a great advantage of pairing--the pair may come up
with something no individual could have discovered.  Sometimes this
competition is counterproductive--that's why it can help to have a
facilitator(coach) to de-escalate discussions and keep them focussed on the
ideas, rather than getting personal.  Competition of ideas can come from
novice-expert as well as expert-expert pairs... and should.

[Non-text portions of this message have been removed]
Permalink | Reply | 0 comments |

Gmane