On Monday, October 25, 2004, at 6:36:41 PM, Ken Boucher wrote:
>> Yes. Do you have any issues on the interfaces between teams? Can you
>> discern any differences in the kinds and frequency of inter-team vs
>> intra-team issues?
> We always have issues. We're human. As we do more cross-team stuff we
> discover new issues and find solutions for them. It's really just a
> matter of experience. The more experience we have, the less problems
> we have.
If you really mean this, I'm surprised. I would have assumed that the
universe offered an unending supply of new problems, and that you might get
better at solving them.
> ----
>> Someone (I) did say that problems occur more on the interfaces
>> between teams. I based that on observation of lots of teams with
>> inter-team interfaces.
> Do you feel that if you double the team size you would have more or
> less problems than two teams of the same size in the same room?
What's the starting number? What's the project or projects? And a bunch of
other questions ...
I'm not saying what to do. I'm saying that teams will have problems on
their interfaces; that feedback inter-team tends to be slower; that team
goals tend not to be completely aligned. And therefore, team divisions need
to be made with those things in mind.
> ----
>> > Basicly, there seem to be three choices to me.
>> > 1) Never hire more than X number of people. (8-12?)
>> > 2) Learn how to have large single teams work well. (20+?)
>> > 3) Learn how to have multiple teams work together well.
>> If those were the only choices, I'd pick number 3 also.
>>
>> However, I would prefer this choice:
>>
>> 4) Organize a large group into teams in such a way as to minimize
>> coupling and maximize cohesion.
> I'm not sure how #4 is different from #3. I must be missing something.
Number three seems to be about helping existing teams work together. Number
four is about how to define what the teams are. I'm supposing that teams
have responsibilities, and that different allocations of responsibility
will work differently well.
> ----
>> It's good to have people with passion. Do you translate your
>> observations about GUI work above into specialists in other areas,
>> like database, or input formatting, or reporting? I ask because I
>> understand the general XP guideline to be Team Code Ownership, and
>> that the usual guideline is that specialization is for insects, not
>> programming teams.
> Specialization is for people who like it. Generalization is for
> people who like that. Programming teams are composed of the right
> people. The right people may be as simple as whomever shows up. I
> know of nothing in XP that says "If you have multiple teams you can't
> move between teams as often as is best for you and the larger
> organization."
I inquired in another reply just what you mean by the notion of multiple
teams if people can move among them at will. That notion doesn't map well
into my understanding of separate teams, so you must be using the term
differently from how I would.
No need to answer twice. And the group rules don't even require you to
answer once. :)
> ----
>> If our teams are to be truly agile, making a decision, other than
>> for the moment, might not be the thing to do.
> Our organization has a phrase we like. "Forever, for now". I'm not
> aware of many decisions that are other than for the moment. (Deciding
> to hire someone comes to mind however.)
Yes, well. This is an unusual definition of the term "decision" and I'd
suggest that in communicating with other users of the same word, that
something needs to be said that distinguishes destination setting from
selection of travel carrier from steering.
> ----
>> I could be wrong, certainly, about the best way to do it.
> Actually, I have no worries about finding "the best way". I doubt
> there is one, and if there is I doubt anyone has enough experience to
> know what it is.
> What I have heard is that some people here think such a thing
> shouldn't be tried. That's fine. That's why I ask these questions.
I'm making no representation about what should be done, much less what
should be tried. I'm predicting that there will be a larger number of
problems across a GUI / model interface than might occur with some
different breakdown. But I'm basing that on what I think is a more um,
conventional use of the word "team" than you may be operating with.
Ron Jeffries
www.XProgramming.com
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
