On Monday, October 25, 2004, at 9:22:35 AM, Ken Boucher wrote:
>> Ken suggests a split between GUI and Model, and William (and I)
>> recommend against it;
>>
>> Ken suggests less of a split between Customer (domain) and
>> Programmer, and William reminds us to keep the roles separate.
>>
>> Now I'm suggesting to all of us that perhaps the Whole Team /
>> Sitting Together notion is at the core of what makes things work
>> well, and that we all have reason to know it.
>>
>> Now what shall we do about these GUI persons and model persons?
> First of all, having multiple teams sitting together in a single room
> isn't really a problem to me since that's the current setup in our
> office anyway. We have smaller team stand up daily and a larger team
> sit-down (just too many people - by the time everyone says "hi" we
> want to sit down) weekly.
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?
> So I'll scribble out some places my minds been at lately and we'll
> see where that goes.
Cool ...
> I feel it's pretty much a given that after a certain size, an XP
> team becomes less productive. If you have customers who are willing
> to pay to double your staff because they have that much work for you,
> then there's some opportunity there that I just don't want to give an
> offhand "No" to. I'd like to think about this for a bit. I hate to
> refuse to employ more agile programmers if I got the chance, just
> because I didn't think I could get two agile teams to work with each
> other.
Please note that so far, no one has said not to hire more programmers, not
to grow, nor that two agile teams cannot work with each other.
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.
> 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. (2-3 by 8-12?)
> I've had more luck with #3 than #2 and I don't like #1. But that's
> just my experiences talking. Other people may have had other
> experiences.
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.
And I point out that if GUI people and model people are in separate teams,
there will be a lot of interfacing across that boundary. And I /suspect/
and /suggest/ that there might be a better organization per item 4) than
breaking up that way.
> The more I think about it, the more the belief that two agile teams
> have an inherent inability to work together just really makes me say
> WTF? I must be missing some really bad experiences here. Heck, I've
> had some bad experiences, but I can't think of anything bad enough to
> make me go there.
No one has said that two agile teams have an inherent inability to work
together. Making translations like that from what people actually do say
may be an obstacle to rapid and effective understanding.
Someone (I) said that problems occur more on the interfaces between teams.
> If someone was doing full time GUI work, I think they would be more
> likely to come up with some really good GUI tests, some great
> usability knowledge, and some wonderful skillsets that the whole team
> would benefit from. I don't see someone who doesn't have that focus
> getting there that easily unless we deliberately hire someone with a
> passion for it. That's also not a bad way to go.
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.
> If you're running multiple products, and especially if you're doing
> branding, it seems to me that the GUIs are sharing as much code as
> the model apps, unless of course you insist that they all be in
> seperate code bases and cross-team reuse simply doesn't happen.
Yes, I would hope that the GUIs would share code in a similar fashion,
though it wouldn't surprise me if there was a bit less (or even a bit more)
as a function of how similar or different the various GUIs were.
> I
> guess that's one of those decisions you have to make when you have
> enough success to be able to double the size of your organization.
I guess it isn't one of those decisions you have to make. You listed three
possibilities. I raised it to four, with one specific suspicion: GUI /
model split may not be ideal.
There may be no reason to make a decision. If our teams are to be truly
agile, making a decision, other than for the moment, might not be the thing
to do.
> I can almost seeing the model code as providing a service to the GUI
> screens. Wouldn't it be interesting if the GUI team owned all the GUI
> acceptance tests and the GUI programmers were the customers of the
> model app? They could even write the model acceptance tests. I'll
> have to think about that some more.
Yes, it's an interesting model, and the one that I'd go to if I were going
to split on GUI / model lines, which I would try not to do. The reason that
I wouldn't is that this would make the GUI people part of the "customer"
for the model people (at a sort of "cross-product" or "multi-product"
level) and that doesn't feel as dynamic as my intuition says is possible or
desirable.
I'd be more inclined to start with a kind of "serial pairing" relationship
between GUI people and model people, but to have them associated in their
own minds with the same story, the same product, the same big-C Customer.
I could be wrong, certainly, about the best way to do it. My bigger
interest in this posting is to suggest that there are more ways to do it
than the ones you've offered so far, i.e. that you might be being a bit
more binary (digital?) than would be ideal.
It is true that there are 10 kinds of people in the world.
But there are more than 10 ways to do most things.
Ron Jeffries
www.XProgramming.com
Only the hand that erases can write the true thing. -- Meister Eckhart
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/
