--- In extremeprogramming@yahoogroups.com, William Pietri
<william@...> wrote:
>
> Heh. CafePress doesn't seem to allow customized cats. Yet, anyhow.

No, you need to print out captions and glue them. <http://xkcd.com/262/>

--- In extremeprogramming@yahoogroups.com, Tim Ottinger
<linux_tim@...> wrote:
>
> BTW: My biggest peeve (after meaningful names, one-effect per line,
dropping gratuitous vertical whitespace, and obviating comments) is
that the indent is perceptible.  One-space and two-space indents make
me very uncomfortable.  I suspect they're to make deep indenting more
palatable, a goal I loathe.  I like to see three or four space
indents.   I've considered moving all my code to five or six spaces,
so that indenting more than one or two levels becomes nearly
intolerable.  :-)

The first piece of "somebody else's code" I ever had to maintain was a
C program that was formatted with one space per indent, no vertical
whitespace, and was (IIRC) about 1,000 lines long with only 2 or 3
functions.

That was an experience.

Has anybody done much with telepresence and XP teams? Like others, I've
struggled for years with clients who want options other than having
everybody in one room. I've been hearing rumblings about telepresence
for a while, but Bob Cringely is the first writer I trust who thinks
they live up to a lot of the hype:

     http://www.pbs.org/cringely/pulpit/2007/pulpit_20070831_002850.html

Naturally, spending $350k plus $18k monthly per room is not an option
for most of us. But I'm wondering:

a) Has anybody had a chance to use this tech in a software development
context?

b) Have people tried cheaper always-on screens in their team rooms to
connect remote people?


It seems to me that one of the big problems with remote participants and
XP is that one has to consciously act to pull them in to a
conversation.  I'm wondering if even a cheap telepresence rig would help
chip away at that.

Curiously,

William


--
William Pietri - william@... - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
Can you see the future? Prove it at http://www.longbets.org/

William Pietri wrote:

> It seems to me that one of the big problems with remote participants and
> XP is that one has to consciously act to pull them in to a
> conversation.  I'm wondering if even a cheap telepresence rig would help
> chip away at that.

I don't know about your pipes, but on ours VNC is too freakin' slow.

Can I hold out for a holograph of a real pair sitting next to me?

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

On 9/1/07, julescov <jules@...> wrote:
>
> The first piece of "somebody else's code" I ever had to maintain was a
> C program that was formatted with one space per indent, no vertical
> whitespace, and was (IIRC) about 1,000 lines long with only 2 or 3
> functions.
>
> That was an experience.
>

Was your first commit message "no code changes. pretty printed to not
be so terrible to read" ?   :)

Jtf

--
http://www.developertesting.com/
http://www.junitfactory.com

Jeffrey Fredrick wrote:

> Was your first commit message "no code changes. pretty printed to not
> be so terrible to read" ?   :)

Such "first piece of somebody else's code" typically come with team and boss
pressure to don't "change anything you don't need to because you might break
it!"

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

Phlip wrote:
> I don't know about your pipes, but on ours VNC is too freakin' slow.
>

Amen to that.

However, I was thinking about something a little different. More like a
window between two offices to make them one. Except with bits. Not for
pairing, but for chatting with colleagues.


> Can I hold out for a holograph of a real pair sitting next to me?
>

That's the ideal. Then you wouldn't even have to say, "Would you like a
mint? No? Really, they're *excellent* mints. You should have one."

William

William Pietri wrote:

> That's the ideal. Then you wouldn't even have to say, "Would you like a
> mint? No? Really, they're *excellent* mints. You should have one."

And the holograph of my room would be ... straightened up. (-;

--
   Phlip

Please RSVP for the next BayAPLN Meeting!
Enterprise Agile Software Development
in an On-Demand World





September 11th - 6:30pm - 9:30pm
Location: Microsoft Offices, One Market Street, San Francisco

RSVP: RSVP AT bayapln.org

TOPIC: Salesforce.com has recently completed an agile transformation of a
two hundred person team within a three month window.  This is one of the
largest and fastest ?big-bang? agile rollouts.  This talk discusses why we
chose to move to an agile process, how we accomplished the transformation
and how we are applying agile software development at scale.

We will also cover effective release planning, automation and test focused
development and tools for driving communication across your organization.
IMPORTANT: Please indicate if you would like food at the meeting.
Sandwich, drink, cookie and chips for $7. We will buy the food and get it
delivered. You pay for it on arrival and eat it!  The last few meetings we
have ordered more food than required. So we're changing the model - we
will only be ordering food for those folks who indicate that they WANT it
and we'll be collecting the $7 for it at the door. If you can't make the
meeting and you've ordered food please let us know. Thanks.

Chris Fry Bio
Chris Fry is a Senior Director at Salesforce.com responsible for platform
software development. He specializes in Software as a Service and creating
and leading agile teams.   He is the author of JSR-173 (Streaming API for
XML) and has led the implementation and deployment of massively scalable
Web Services at Salesforce.com and BEA.  He received his Ph. D. in
Cognitive Science from UCSD and was a post-doctoral fellow at UC Berkeley.

Steve Greene Bio
Steve Greene is the Director of Tools & Process at Salesforce.com and is
responsible for the implementation and evolution of agile methodologies
and supporting tools for the Technology organization.  He has held
numerous senior management positions at On-demand startup and large
enterprise software companies including DigitalThink, Hyperion,
PeopleSoft/Oracle, SPC and AOL.  He brings a wealth of expertise and
experience in productivity, process and product delivery.  He holds a BS
in Computer Engineering from San Jose State University.




You can keep up to date at our website:  http://www.bayapln.org
Or by joining the BayAPLN Yahoo Group -
http://finance.groups.yahoo.com/group/BayAPLN/

--David Chilcott
drc@...
www.outformations.com
510.655.7122 Voice

Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the
Mystery.


[Non-text portions of this message have been removed]

Rob Park wrote:

> Whitespace is actually 1 of our formatting issues. As much as I
> prefer very little whitespace and making whitespace communicate
> something (i.e. logic breaks), I would happily inject lots of
> whitespace if that were the team's preference.



JB wrote:
Interesting. Does your language make it costly to extract logical breaks
into separate methods?



----------------

No, it's not costly and I could see that taken to the limit, no method
should have /any/ whitespace in between lines.

The cost of that would be my sanity. ;-)

rob.





[Non-text portions of this message have been removed]

0-space indents on HTML does sound crazy. although worth a try. :-)



Does anyone have any preferences/arguments/documentation/examples for
spacing/formatting in complex TSQL queries/stored procedures?



rob.



From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of William Pietri
Sent: Friday, August 31, 2007 6:16 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Coding Standards



J. B. Rainsberger wrote:
> Not for me. I tend to use 4-space indents for HTML.
>

I encourage folks to try zero-space indents for HTML. I used to indent
my HTML because, well, that seemed like the thing to do. But then a
friend, who is an ascended master as far as HTML goes, told me he didn't
indent at all, and just uses some newline-based grouping.

I thought he was crazy, but I gave it a try. Eventually I decided I
liked that a lot, because

a) it's not a programming language,
b) my editor shows me tag balance better than indenting would, and
c) when I'm dealing with templates, there's no worrying about indent
collision

As a bonus, it's faster to transmit, too.

This approach is probably not for everybody, but I don't miss HTML
indents at all.

William

--
William Pietri - william@... <mailto:william%40scissor.com>  -
+1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
Use your geek-fu to fight poverty: http://www.mifos.org/





[Non-text portions of this message have been removed]

To me, "Sometimes there are good reasons for diverging from the standard" is
true, but is really just an extension of the standard.

Cases like this should be handled consistently over time.



rob.



From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of George Dinwiddie
Sent: Friday, August 31, 2007 6:24 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Re: Collective Code Ownership



J. B. Rainsberger wrote:
> Steven Gordon wrote:
>
>> In order to make diffs meaningful, pick a format for storing in version
>> control and have the IDE convert to that format before check in.
>
> That's fine. I suppose if we never forget to do that, I have no
> objection, except that it seems unnecessarily risky compared to just
> using the same settings. I suppose I'd have to try it both ways.

Actually, you can generally have the version control system do it
automatically, if it's a problem. I prefer voluntary, human-decided
format, myself. Sometimes there are good reasons for diverging from the
standard.

"A foolish consistency is the hobgoblin of little minds, adored by
little statesmen and philosophers and divines." -- Ralph Waldo Emerson

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------





[Non-text portions of this message have been removed]

Rob Park wrote:

> Does anyone have any preferences/arguments/documentation/examples for
> spacing/formatting in complex TSQL queries/stored procedures?

O'Reilly's "ant book" for Oracle SQL*Plus has some super-cute
recommendations for normal select statements. In a monospace font...

select * from Frogs
  where species_id = 42
    and habitat_id = 92011
  order by latin_name;

That puts a vertical blank gutter down the 7th column, with operators on its
left and operands on the right.

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

Charlie Poole wrote:

> For example, I'll often create an interface that is intended
> for users of an object, leaving out the methods meant
> for the creator of the object. That means I have fewer
> choices when I go to use the object - fewer items in the
> Intellisense - and that simplifies my life and seems to
> make the code easier to understand.

I do that, too. I think the Interface Segregation Principle is typically
undervalued.

Cheers, Ilja

George Dinwiddie wrote:
> On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
>> Hello all,
>>     When doing TDD, I get confused sometimes regarding two principles:
>> "YAGNI" and "depends on abstraction not on concretion".
>>     For example, I'm developing a class  named FileSearcher that depends
>> on another class named FileCounter.So I inject FileCounter in
>> FileSearcher.
>>     Following "depends on abstraction not on concretion" principle,
>> FileSearcher should use a FileCounter interface. Then I create an
>> implementation class for that interface and inject in FileCounter.
>>     Following YAGNI principle: man I don't need that interface, so I
>> will get rid of it and receive the implementation class as a parameter.
>> If I need two different implementations someday then I create an
>> interface.
>
> In this scenario, I would follow YAGNI.  Not everything needs to be an
> abstraction, particularly if it's only used in one place.  Like you say,
> when you need two implementations, that's the time to turn FileCounter
> into an interface.

Which might be as soon as you write unit tests for FileSearcher.

Cheers, Ilja

Ilja Preuss wrote:

>> In this scenario, I would follow YAGNI.  Not everything needs to be an
>> abstraction, particularly if it's only used in one place.  Like you say,
>> when you need two implementations, that's the time to turn FileCounter
>> into an interface.
>
> Which might be as soon as you write unit tests for FileSearcher.

Not everyone follows (or has even heard of) the rubric that unit tests shall
not touch the file system. Some of us might even write a searcher that
populates a temporary folder with goodies and searches for them.

The rubric exists to force abstractions to emerge. So you have simply stated
the goal of Premature Generalization in another way.

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

Ilja Preuss wrote:
> George Dinwiddie wrote:
>> On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
>>> Hello all,
>>>     When doing TDD, I get confused sometimes regarding two principles:
>>> "YAGNI" and "depends on abstraction not on concretion".
>>>     For example, I'm developing a class  named FileSearcher that depends
>>> on another class named FileCounter.So I inject FileCounter in
>>> FileSearcher.
>>>     Following "depends on abstraction not on concretion" principle,
>>> FileSearcher should use a FileCounter interface. Then I create an
>>> implementation class for that interface and inject in FileCounter.
>>>     Following YAGNI principle: man I don't need that interface, so I
>>> will get rid of it and receive the implementation class as a parameter.
>>> If I need two different implementations someday then I create an
>>> interface.
>> In this scenario, I would follow YAGNI.  Not everything needs to be an
>> abstraction, particularly if it's only used in one place.  Like you say,
>> when you need two implementations, that's the time to turn FileCounter
>> into an interface.
>
> Which might be as soon as you write unit tests for FileSearcher.

Maybe.  Or maybe not.  The bog-standard FileCounter might provide
everything my test need.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hello, Phlip.  On Sunday, September 2, 2007, at 3:07:44 PM, you
wrote:

> Not everyone follows (or has even heard of) the rubric that unit tests shall
> not touch the file system. Some of us might even write a searcher that
> populates a temporary folder with goodies and searches for them.

> The rubric exists to force abstractions to emerge. So you have simply stated
> the goal of Premature Generalization in another way.

Yes. I find that when building up, avoiding /all/ file accesses is
overkill. In legacy code, however, where people have all kinds of DB
stuff tangled with app-specific stuff, Then testing becomes really
hard. Somewhere from a couple of file accesses to touching Oracle on
every test, a line needs to be drawn. My guess is that Feathers's
guideline of NO such things is a good starting point to deviate from
... but that wise and practiced people will deviate to advantage.

Ron Jeffries
www.XProgramming.com
I could be wrong, of course. It's just not the way to bet.

From: "Ron Jeffries" <ronjeffries@...>
To: <extremeprogramming@yahoogroups.com>
Sent: Sunday, September 02, 2007 6:09 PM
Subject: Re: [XP] YAGNI and Abstraction


> Hello, Phlip.  On Sunday, September 2, 2007, at 3:07:44 PM, you
> wrote:
>
>> Not everyone follows (or has even heard of) the rubric that unit tests
>> shall
>> not touch the file system. Some of us might even write a searcher that
>> populates a temporary folder with goodies and searches for them.
>
>> The rubric exists to force abstractions to emerge. So you have simply
>> stated
>> the goal of Premature Generalization in another way.
>
> Yes. I find that when building up, avoiding /all/ file accesses is
> overkill. In legacy code, however, where people have all kinds of DB
> stuff tangled with app-specific stuff, Then testing becomes really
> hard. Somewhere from a couple of file accesses to touching Oracle on
> every test, a line needs to be drawn. My guess is that Feathers's
> guideline of NO such things is a good starting point to deviate from
> ... but that wise and practiced people will deviate to advantage.

Of course, the other issue on file system, data base, network access
or other expensive tests is that they are expensive; most projects are
going to hit a point where trying to run all the tests in the "TDD
window" is going to impact the process, either by running tests
less frequently or breaking the flow.

Learning how to abstract expensive resources, classify tests and
similar strategies is going to pay off. You may not need to use it
all the time, or on all  projects, but sooner or later you're going to
find it useful.

John Roth



>
> Ron Jeffries
> www.XProgramming.com
> I could be wrong, of course. It's just not the way to bet.
>
>

> If you can't understand this method from the source and the
> tests, contact Brad Stiles at xxx xxx-xxxx and collect $20.

Well, aside from the last part, and the part about cluttering up the
source with *comments* that have nothing to do with the code itself,
(which is what I'm trying to avoid), the thing I was trying to avoid,
that's pretty much what I do. :)

Brad

Hello, John.  On Sunday, September 2, 2007, at 9:16:05 PM, you
wrote:

>> Yes. I find that when building up, avoiding /all/ file accesses is
>> overkill. In legacy code, however, where people have all kinds of DB
>> stuff tangled with app-specific stuff, Then testing becomes really
>> hard. Somewhere from a couple of file accesses to touching Oracle on
>> every test, a line needs to be drawn. My guess is that Feathers's
>> guideline of NO such things is a good starting point to deviate from
>> ... but that wise and practiced people will deviate to advantage.

> Of course, the other issue on file system, data base, network access
> or other expensive tests is that they are expensive; most projects are
> going to hit a point where trying to run all the tests in the "TDD
> window" is going to impact the process, either by running tests
> less frequently or breaking the flow.

> Learning how to abstract expensive resources, classify tests and
> similar strategies is going to pay off. You may not need to use it
> all the time, or on all  projects, but sooner or later you're going to
> find it useful.

Oh yes, I completely agree. One needs to know how to do it, and
important not to build things that get all entangled. At the same
time, the tests aren't complete without SOME test of the file
connection, DB connection, and so on. I think Feather's rule is a
good starting point, and expect never to finish there.

Ron Jeffries
www.XProgramming.com
The model that really matters is the one that people have in
their minds.  All other models and documentation exist only to
get the right model into the right mind at the right time.
   -- Paul Oldfield

> Actually, you can generally have the version control system do it
> automatically, if it's a problem.

Sure, as long as your version control system is one that updates the
working copy when a change is made to a commit without the working
copies involvement.

For instance, if one were to do that with Subversion, one's working
copy, with respect to the files just committed, would not match the
repository.  The practice of modifying the commit transactions on the
server side is actively discouraged.


> I prefer voluntary, human-decided format, myself.  Sometimes there are
good reasons for diverging
> from the standard.

Yup.

Brad

This recommendation was interesting: "You can magnify the effect of a
powerful language by using a style called bottom-up programming, where
you write programs in multiple layers, the lower ones acting as
programming languages for those above."

You might work top down, where each layer is a specification for the
language below it. Or as PJ Plauger wrote in "Programming on Purpose"
some problems work best left to right, or right to left or inside to
outside. ;-)

William Pietri wrote:
>
> protoiyer wrote:
> > However, XP seems to advocate a stand that this is not required, and
> > that you can actually grow a program by concentrating on the parts
> > under consideration (being test driven) at any point of time.
> >
> > Am I missing something here? Is there any real overlap between what
> > XP/TDD advocates and what Graham says (about working alone, work in
> > long stretches, holding the program in its entirety in one's head etc.)
> >
>
> I think your instinct is correct; his advice doesn't really take XP
> approaches into account. However, I still think a lot of the attitude
> applies, just in different ways.
>
> He's right that the more context you have in your head at once, the
> better off you are. However, in XP, we manage that differently. Instead
> of keeping the context in one head, we share it among the team. Instead
> of expecting to remember everything, we write tests so that we get
> reminded of the little details when we need to. And we keep both our
> production code and our tests as readable as possible, so that the
> stored knowledge is easily retrieved.
>
> At least in my experience, this has three effects. One, because we have
> offloaded a lot of little details, what's in our heads is often broader
> or more subtle stuff. Two, with more perspectives, the solutions are
> better. And three, since we've built up a supporting context, it's safer
> to leave and pick up the next day.
>
> And I think there's something more subtle, too. Without fear that we
> have lost some crucial detail, we're braver. I don't think that makes a
> big difference early on, but it's crucial in allowing refactoring and
> cleanup of cruft that otherwise kills code bases.
>
> William
>
> --
> William Pietri - william@... <mailto:william%40scissor.com> -
> +1-415-643-1024
> Agile consulting, coaching, and development: http://www.scissor.com/
> <http://www.scissor.com/>
> Instant video gratification: http://www.sidereel.com/
> <http://www.sidereel.com/>
>
>

Exactly.

Many people confound the final form with the order in which things were
built.  Just because the end result may be these kind of DSL layers does not
mean that any one layer was designed or completed before any other layer.

I say let the user stories guide the order in which parts of the eventual
layers are built and let expressiveness and reuse guide how those parts are
eventually assembled into coherent layers via refactoring.

Steve

On 9/3/07, Jim Standley <JLStandley@...> wrote:
>
>   This recommendation was interesting: "You can magnify the effect of a
> powerful language by using a style called bottom-up programming, where
> you write programs in multiple layers, the lower ones acting as
> programming languages for those above."
>
> You might work top down, where each layer is a specification for the
> language below it. Or as PJ Plauger wrote in "Programming on Purpose"
> some problems work best left to right, or right to left or inside to
> outside. ;-)
>
> William Pietri wrote:
> >
> > protoiyer wrote:
> > > However, XP seems to advocate a stand that this is not required, and
> > > that you can actually grow a program by concentrating on the parts
> > > under consideration (being test driven) at any point of time.
> > >
> > > Am I missing something here? Is there any real overlap between what
> > > XP/TDD advocates and what Graham says (about working alone, work in
> > > long stretches, holding the program in its entirety in one's head
> etc.)
> > >
> >
> > I think your instinct is correct; his advice doesn't really take XP
> > approaches into account. However, I still think a lot of the attitude
> > applies, just in different ways.
> >
> > He's right that the more context you have in your head at once, the
> > better off you are. However, in XP, we manage that differently. Instead
> > of keeping the context in one head, we share it among the team. Instead
> > of expecting to remember everything, we write tests so that we get
> > reminded of the little details when we need to. And we keep both our
> > production code and our tests as readable as possible, so that the
> > stored knowledge is easily retrieved.
> >
> > At least in my experience, this has three effects. One, because we have
> > offloaded a lot of little details, what's in our heads is often broader
> > or more subtle stuff. Two, with more perspectives, the solutions are
> > better. And three, since we've built up a supporting context, it's safer
> > to leave and pick up the next day.
> >
> > And I think there's something more subtle, too. Without fear that we
> > have lost some crucial detail, we're braver. I don't think that makes a
> > big difference early on, but it's crucial in allowing refactoring and
> > cleanup of cruft that otherwise kills code bases.
> >
> > William
> >
> > --
> > William Pietri - william@... <william%40scissor.com> <mailto:
> william% <william%25>40scissor.com> -
> > +1-415-643-1024
> > Agile consulting, coaching, and development: http://www.scissor.com/
> > <http://www.scissor.com/>
> > Instant video gratification: http://www.sidereel.com/
> > <http://www.sidereel.com/>
> >
> >
>
>
>


[Non-text portions of this message have been removed]

Hello, Robert.  On Thursday, August 23, 2007, at 4:37:31 PM, you
wrote:

> Ron Jeffries wrote:

  >> It is true that we don't propose putting everyone in the universe in
  >> one big room. However, as we used to say, "End to end is further
  >> than you think," and where we split the team there will be delay and
  >> waste.

> And speed and benefit. Otherwise you wouldn't split, would you?

I wouldn't.But people do it all the time. It is almost standard in
waterfallish organizations to believe that using separate analysts
is a good thing. I am stating unequivocally, I hope, that I believe
that it is not.

> So it's a trade-off. I agree that in the past the split has typically
> been in a foolish place. But that doesn't mean there that any split is
> only bad.

  >> It seems to me that splitting the team between analysis and the rest
  >> of development is discernibly fraught.

> I'm not sure what you mean by splitting and team. I'm arguing for
> analyis, and analysts. I agree they should work together with
> developers, users, and stakeholders. If that means you regard them as
> part of the team, that's fine with me.

I'm not saying I /regard/ them as members of the team, I'm saying
they should really /be/ members of the team. If they are in a
separate organization, if they serve as a relay from users and
customers to developers, if they are not co-located with the team,
that is evidence that what I'm recommending is not being done.

  >>  The Agile / XP way is to
  >> cycle quickly between feature idea, running feature, and learning
  >> what the feature tells us about the next feature idea. Separation of
  >> analysis people from developing people gets in the way of that. I'm
  >> not comfortable with an articulation there.

> I'm not sure who you mean by "us", or separation, or even by
> articulation. I was saying there is a place for analysts, and that
> they do not need to be programmers too. Do you disagree with that?

Not entirely, but I'll point out that as they are not customers and
not programmers, they will not be native speakers of either
language. I'd prefer programmers with analysis skill, directly
talking with the people with the need.

  >>  > Ok, I find this interesting, but I don't really see much evidence that
  >>  > this is where Agile is pointing. In particular, I don't see any
  >>  > techniques being advanced for people with different skills working
  >>  > together, unless they are both programmers.
  >>
  >> "Individuals and interactions over processes and tools" is asking us
  >> to bring people together. As for ways to work together, the whole
  >> touchy-feely side of the Agile community is working on that,
  >> bringing in ideas that have been around a long time.

> So what touchy-feeling things are you thinking of? I think I'm in
> touch with that part of the Agile community, and I don't think there
> is much that addresses this issue.

Do you mean that there isn't much written about HOW to do it? That's
true. That doesn't mean people can't do it, it just means that
they'll have to rely on their experience and existing skills in
finding out what is needed and implementing it.

  >> And there are planning games and estimation games, and so on.

> Well yes indeed, and I like them. But I don't see, in your view, who
> gets to play them. Who plays the customer?

Customers are a good choice to play customer.

  >>...
  >>  > And so we return to "whole team", a concept which I don't understand.
  >> What is it that you don't understand about whole team?

> Let me begin with this question:
> How can you determine if a project has adopted this practice or not?

I would observe the team and see whether they have repeated, day to
day or week in / week out requirements for communications with
people who are basically not in the room with them, who have other
responsibilities, who are not essentially dedicated to the project.

If they have those things, then they have not adopted the Whole Team
practice as well as they might.

It's about waste. Is there delay in communication, or significant
loss of information as in use of documents where conversation would
take place, or extra layers of conversation where direct could take
place? Then this is waste and it needs to be eliminated.

  >>  > Ok, so we seem to agree that analysts have a role. But there is very
  >>  > little said, perhaps nothing, about the role of analysts on an agile
  >>  > team. Can you think of something?
  >>
  >> I don't do roles, I do skills. The need for the skill is obvious,
  >> surely? The need for a person with a hat, not so much. That's one
  >> way to get the skill, but they should leave the hat home and
  >> identify with the team not with their profession.

> I don't see this. The customer is a role, isn't it? And doesn't the
> customer get to decide business value? Even if a developer has more
> business skill? And the same for developers and the technical side?

I don't understand your point. We need the analysis skills. We do
not need the analysis role to be embodied in a person. We need
everyone on the team to do everything that they can, as well as they
can, all the time. We want to avoid specialization where possible,
as it produces hand-offs, and hand-offs are waste.

  >>  > And I still don't understand "whole team", other than meaning "hey
  >>  > everyone, let's play nice!".
  >> I don't think it even means that. I think it means that the
  >> principle is to have all the key players together, fully engaged in
  >> the project. And "key" is probably further than we think. I hope
  >> they'll play nice, but if once in a while they want to wrestle,
  >> that's OK with me.

> So, that's good to hear. And I agree that practice is sensible. I
> don't think "whole team" is a good name for it though, because there
> are also forms of group engagement where more than one team is
> involved.  Also, teams have roles, and while it is admired to be able
> to play "out of position", it is typical to regard one's role as a
> primary responsibility.

That notion is, in my opinion, fundamentally at odds with Agile and
Lean principles.

  >>  > ... That context, their workplace, for example, is a key part of
  >>  > the subject.
  >>
  >> Yes, that's true. But they don't forget everything in two minutes,
  >> and the team can visit them. I'm trying to avoid the two-stage
  >> conversation...
  >> ...by having the analyst in the team, not separate. And ideally, until
  >> their brains fade, I'd like to have users on the team as well.

> Hmm. I still don't know quite what you mean by "in the team". I
> certainly mean any analysts to be strongly engaged and co-located with
> developers. Is that what you mean?

Pretty much. We agree on that. It seems rarely to happen, however,
at least where I hang out. More commonly, we find drive-by analysis.

> Also, the issue isn't just brain fade. The other factors are things
> like situated cognition, and the influence of other people. It just
> isn't enough to ask
> people, because then they themselves need to be analysts.

You seem to imagine that analysts have some magical power to divine
from normal humans things that the normal humans themselves cannot
ascertain. This seems to me to be highly unlikely: a thing cannot
give what it does not have.

  >>  > Ok, so does that mean the Customer is not allowed to have their own
  >>  > people? Their own analysts, for example?

  >> "Their own people"? I don't understand that phrase.

> Well, for example, are you happy for analysts to be co-located and
> engaged with developers who are primarily responsible for the business
> decisions, as part of the customer team?

I do not expect developers to be responsible for the business
decisions, which is how I parse the above sentence. But I assume you
really mean "are you happy for analysts who are primarily
responsible for the business decisions to be co-located ...".

I am not happy for that to be the case either. Analysts, as a rule,
not being from the core business unit being served, are not capable
of being responsible for the success of the project. The business
responsibility will be better retained in the business unit paying
for and receiving the software.

  >> As I understand things at 3M, products are created by fully
  >> empowered teams that include all the resources they need, from
  >> marketing to creation to manufacturing to delivery. They can and
  >> should outsource some of these things for efficiency, but their
  >> setup is to have everything they need to create a successful product
  >> and bring it to market.
  >>
  >> I think that's what "whole team" is asking for.

> I can understand how this works when the devlopement organisation is
> also the business organisation, which I understand to be the case with 3M.
> What is not clear to me is how it might work when they are not the
> same organisation.

Business organization "hires" development organization, which is
dedicated to the business organization's problem, and works
according to the business organizations's ordering of features.

That, in one sentence, is exactly what Agile is, in my opinion.

Ron Jeffries
www.XProgramming.com
The central "e" in "Jeffries" is silent ... and invisible.

Did any body try a new tool Analyst Real Team System 7.0 (ARTS)(
www.analysttool.com ).  It allows to track user stories, requirements,
tasks, test cases, etc.  It is fully configurable for extreme
programming. It includes a visual tool for establishing traceability
relationships. It was produced by Goda Software, Inc.

William Pietri wrote:
> Has anybody done much with telepresence and XP teams? Like others, I've
> struggled for years with clients who want options other than having
> everybody in one room. I've been hearing rumblings about telepresence
> for a while, but Bob Cringely is the first writer I trust who thinks
> they live up to a lot of the hype:

I'm surprised James or Gary hasn't posted yet, but that's the kind of
stuff they are doing - except with their customers. They have a
dedicated link from Missouri to Virginia they run video from, and they
have several conference rooms set up so that you can call any of the others.

I found it worked fairly well - it wasn't quite the same as having
someone there (indeed, the customers still fly out regularly), but
couple that with something like the new Microsoft Surface stuff, and
that's pretty close.

One thing I always saw highly encouraged was webcams - even if we were
calling our customer, we brought up the webcam so that we could see
facial expressions, show sketches, etc, etc. I can't imagine it would be
a 100% replacement for onsite (far from it), but it is light years ahead
of email or chat.

--
Cory Foy
http://www.cornetdesign.com

Quoting Cory Foy <usergroup@...>:

> William Pietri wrote:
>> Has anybody done much with telepresence and XP teams? Like others, I've
>> struggled for years with clients who want options other than having
>> everybody in one room. I've been hearing rumblings about telepresence
>> for a while, but Bob Cringely is the first writer I trust who thinks
>> they live up to a lot of the hype:
>
> I'm surprised James or Gary hasn't posted yet, but that's the kind of
> stuff they are doing - except with their customers. They have a
> dedicated link from Missouri to Virginia they run video from, and they
> have several conference rooms set up so that you can call any of the others.
>
> I found it worked fairly well - it wasn't quite the same as having
> someone there (indeed, the customers still fly out regularly), but
> couple that with something like the new Microsoft Surface stuff, and
> that's pretty close.
>
> One thing I always saw highly encouraged was webcams - even if we were
> calling our customer, we brought up the webcam so that we could see
> facial expressions, show sketches, etc, etc. I can't imagine it would be
> a 100% replacement for onsite (far from it), but it is light years ahead
> of email or chat.

We do have very high quality video conferencing equipment, and we use
it extensively to communicate with our Customers in DC.  As far as I
know, no one has tried pair programming across the link, but we
certainly could.

GB.

Hi,

There's developers in the Virginia office??? I thought that was just where
they kept all the business people, safely away from the scary developers. ;)


Thanks,
James

On 9/4/07, Gary Brown <glbrown@...> wrote:
>
>   Quoting Cory Foy <usergroup@...<usergroup%40cornetdesign.com>
> >:
>
> > William Pietri wrote:
> >> Has anybody done much with telepresence and XP teams? Like others, I've
> >> struggled for years with clients who want options other than having
> >> everybody in one room. I've been hearing rumblings about telepresence
> >> for a while, but Bob Cringely is the first writer I trust who thinks
> >> they live up to a lot of the hype:
> >
> > I'm surprised James or Gary hasn't posted yet, but that's the kind of
> > stuff they are doing - except with their customers. They have a
> > dedicated link from Missouri to Virginia they run video from, and they
> > have several conference rooms set up so that you can call any of the
> others.
> >
> > I found it worked fairly well - it wasn't quite the same as having
> > someone there (indeed, the customers still fly out regularly), but
> > couple that with something like the new Microsoft Surface stuff, and
> > that's pretty close.
> >
> > One thing I always saw highly encouraged was webcams - even if we were
> > calling our customer, we brought up the webcam so that we could see
> > facial expressions, show sketches, etc, etc. I can't imagine it would be
> > a 100% replacement for onsite (far from it), but it is light years ahead
> > of email or chat.
>
> We do have very high quality video conferencing equipment, and we use
> it extensively to communicate with our Customers in DC. As far as I
> know, no one has tried pair programming across the link, but we
> certainly could.
>
> GB.
>
>
>


[Non-text portions of this message have been removed]

Quoting James Carr <james.r.carr@...>:

> Hi,
>
> There's developers in the Virginia office??? I thought that was just where
> they kept all the business people, safely away from the scary developers. ;)
>
>
> Thanks,
> James

Yeah, we have developers in VA, but they only do lame-o stuff like
accounting and management reports!  Bleech!  8^)

GB.




>
> On 9/4/07, Gary Brown <glbrown@...> wrote:
>>
>>   Quoting Cory Foy <usergroup@...<usergroup%40cornetdesign.com>
>> >:
>>
>> > William Pietri wrote:
>> >> Has anybody done much with telepresence and XP teams? Like others, I've
>> >> struggled for years with clients who want options other than having
>> >> everybody in one room. I've been hearing rumblings about telepresence
>> >> for a while, but Bob Cringely is the first writer I trust who thinks
>> >> they live up to a lot of the hype:
>> >
>> > I'm surprised James or Gary hasn't posted yet, but that's the kind of
>> > stuff they are doing - except with their customers. They have a
>> > dedicated link from Missouri to Virginia they run video from, and they
>> > have several conference rooms set up so that you can call any of the
>> others.
>> >
>> > I found it worked fairly well - it wasn't quite the same as having
>> > someone there (indeed, the customers still fly out regularly), but
>> > couple that with something like the new Microsoft Surface stuff, and
>> > that's pretty close.
>> >
>> > One thing I always saw highly encouraged was webcams - even if we were
>> > calling our customer, we brought up the webcam so that we could see
>> > facial expressions, show sketches, etc, etc. I can't imagine it would be
>> > a 100% replacement for onsite (far from it), but it is light years ahead
>> > of email or chat.
>>
>> We do have very high quality video conferencing equipment, and we use
>> it extensively to communicate with our Customers in DC. As far as I
>> know, no one has tried pair programming across the link, but we
>> certainly could.
>>
>> GB.
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>