On Sunday, October 24, 2004, at 10:44:11 PM, Ken Boucher wrote:
>> I'd expect problems on the interface between any two teams, especially if
>> it was an active interface, subject to a lot of learning and changing. And
>> I'd expect that the GUI / model interface would have a lot of that.
> I'd expect initial problems, but if two xp/agile teams couldn't find ways to work
> together,
> communicate, provide freedback to each other, etc. then I would be asking a lot of
> questions.
Yes ...
> Perhaps one GUI member could pair with on project member for scoping out the tests or
> for most of or perhaps the entire card. Perhaps a project member could serve as a
> "model
> customer" or "model consultant". Perhaps a GUI member could serve as a "GUI interface
> consultant", so the model people know what needs to be passed across the layer.
> There's
> no reason all the teams can't still be in the same room and if they couldn't there's
> no
> reason someone couldn't visit for a day or a week or an iteration. That might prove
> very
> educational to everyone.
Yes ...
> But I'm sure two agile teams could find their own perfect solutions. If not, I'd
> seriously
> start looking at why.
I'd expect this to be unlikely for a number of reasons:
First, perfect happens ever so rarely.
Second, I believe you've ruled out the "perfect" solution.
Third, human institutions, like team boundaries, tend to be preserved
even after they have served their purpose.
I'm just saying "unlikely, mind you. It could happen, of course, that at
least a "pretty good" or even "very good" solution might be found.
One of the things I expect they'd observe is that there are /inevitable/
problems on the interface between any two separate teams. This is literally
a mathematical certainty, coming directly from queuing theory, and a human
certainty as well, coming from the separate objectives and focus that have
made them be two teams rather than one.
Generally speaking, the best places to split teams are on natural
boundaries in the code and objectives. Different products, different
streams of stories, things like that. It's like splitting objects: you want
high cohesion and low coupling, you want relatively stable interfaces
between teams with most of the change inside a team boundary.
But I'm just predicting what I think we'd find, which is that a team split
along an actively-changing, high-learning interface will have problems on
that interface. That might not happen: I could be wrong, as has been known
to occur. But it is what I find whenever I visit organizations built up of
separate teams. It's even what I find when I visit organizations that don't
pair much and that have code specialization: There's usually trouble on the
interface between Jim's code and Jane's code. Organizations with separate
testers develop issues on the code/test boundary.
The "solution", of course, is in working more closely together, in the
practice called /Whole Team/ in our current parlance, and in the practice
which I believe Kent Beck calls /Sitting Together/ in the forthcoming book.
In the case in hand, if your two imagined teams were sensitive enough to
what was going on, I would expect them to evolve the solution of not being
two teams split along GUI / model boundaries, but instead to mix GUI people
and model people together more flexibly, e.g. pairing and going to the same
meetings, and in general being teams split some other way.
Ron Jeffries
www.XProgramming.com
Mixed metaphors are a bright sunny day with no paddle. -- Phlip
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/
