> 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.
So I'll scribble out some places my minds been at lately and we'll
see where that goes.
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.
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.
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.
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.
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. 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 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.
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/
