1 May 2004 01:56

### Re: The Perfect Customer

```Hi Matt,

> I know the answer is that it doesn't matter if they get it
> wrong because early feedback will allow them to make changes
> afterwards but how do you convince a customer of that?

I think it matters, but only very little.  One way to convince
the customer is to make the possibilities visible.  Put various
scenarios on the wall, so that it's easy to see the differences.

Here's one way.  Suppose the customer isn't sure whether to do
story X this iteration or next.  One choice is to do story X this
week.  Take this week's cards and plop them up on the wall.  Draw
a vertical line to the right of these.  Take next week's cards,
and plop them on the wall to the right of the line.

Draw a horizontal line below that whole scenario.

Then use a duplicate set of cards to show the other scenario.  If
you shift story X to next week, you can do a few other stories
from next week to this week.  Call those stories Y and Z.  Plop
them up on the wall, along with the rest of this week's cards, to
the left of the "this week" line.  Put story X, along with any
other "next week" stories, to the right of the line.

Then it's easy to show the cost of getting it wrong.  Let's say X
is more valuable than Y and Z, but you make a mistake and put X
next week instead of this week.  The cost is that you get story X
next week instead of this week.  As partial compensation, you get
stories Y and Z this week instead of next week.  Total cost:  One
```

1 May 2004 03:24

### Re: Re: [OT] Beck invents "Ludicrous Programming"

```Uhh... wasnt that by En Vogue?

-Brian

Jeff Grigg wrote:

>--- Ron Jeffries <jeffries <at> d...> wrote:
>
>
>http://members.rogers.com/nshenoy0424/weblog/2004_04_01_thoughts.html
>
>
>
>I thought the plan-driven approaches already practiced "YNGGI"
>("You're Never Gonna Get It," by Destiny's Child)
>
>
>
>To Post a message, send it to:   extremeprogramming <at> eGroups.com
>
>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
>
>
>
>
>
>
>
```

1 May 2004 06:09

### XPlorations - Configuration Management basics on a page

```(Crossposted from XPlorations)

Configuration Management is an underlying support technology for
continuous integration. I've made a one-page summary of key ideas:

http://www.xp123.com/xplor/xp0404b/index.shtml
Configuration Management Basics on a Page

--
Bill Wake   William.Wake <at> acm.org   www.xp123.com
Contribute pictures to http://www.xp123.com/xplor/room-gallery !

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

```
1 May 2004 11:43

### Re: DSDM is Agile

```Agreed.

I would like to fill in some more background info because I feel
that, as I provided advice on XP to the DSDM consortium for DSDM
v4.2 in 2002/2003, I am implicated in the choice of Enterprise XP
name. During this time I was bound by a non-disclosure agreement so
I could not discuss freely on this list. At this time another XP
advisor on DSDM v4.2, Sean Hanly, expressed within the review
group "I personally am uncomfortable with EnterpriseXP tag and would
prefer that we disassociate the 4.2 work and EnterpriseXP." I think
this was the general view taken by all XP practitioners who worked
on v4.2 but DSDM consortium went ahead with the name anyhow.
To reiterate previous mails, I have used some DSDM techniques in
conjuntion with XP and believe that we have things to learn from
each other but do not like "EnterpriseXP" branding.

Rachel Davies

--- In extremeprogramming <at> yahoogroups.com, Steven Gordon
<sagordon <at> a...> wrote:
> Sorry - I mistakenly used a faulty method: assuming that
the "Search Archive" button at
http://groups.yahoo.com/group/extremeprogramming/ would return
references correctly.
>
> And I do agree that not challenging this reference in an email
does not constitute consent.  Furthermore, many people did challenge
the name IndustrialXP.

To Post a message, send it to:   extremeprogramming <at> eGroups.com
```

1 May 2004 12:47

### Re: Re: DSDM is Agile

```On Saturday, May 1, 2004, at 5:43:26 AM, rachelclairedavies wrote:

> I would like to fill in some more background info because I feel
> that, as I provided advice on XP to the DSDM consortium for DSDM
> v4.2 in 2002/2003, I am implicated in the choice of Enterprise XP
> name. During this time I was bound by a non-disclosure agreement so
> I could not discuss freely on this list. At this time another XP
> advisor on DSDM v4.2, Sean Hanly, expressed within the review
> group "I personally am uncomfortable with EnterpriseXP tag and would
> prefer that we disassociate the 4.2 work and EnterpriseXP." I think
> this was the general view taken by all XP practitioners who worked
> on v4.2 but DSDM consortium went ahead with the name anyhow.
> To reiterate previous mails, I have used some DSDM techniques in
> conjuntion with XP and believe that we have things to learn from
> each other but do not like "EnterpriseXP" branding.

Have any of the people who are actually behind "EnterpriseXP" ever done
"pure" XP? I am wondering at least two things: how do they know it needs
something, and how are they qualified to advise on when and how to add
things?

Ron Jeffries
www.XProgramming.com
When all ideas of [XP] is and [XP] is not have been extinguished,
then [XP] reality will manifest itself.  -- Thich Nhat Hanh [Ron Jeffries]

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

```

1 May 2004 13:58

### Anouncing JeffriesXP, WakeXP, YourNameHereXP

```When I'm working with people trying to do XP, there are many practices that
I'll recommend from time to time, as the occasion seems to call for. Some
of the practices have names, like Readiness Assessment, or Big Visible
Chart, and some do not. I feel sure that all of us pull out some
recommended practice from time to time, that fits the immediate need of the
team we're working with.

These are good practices, and they are nicely applicable to teams doing XP,
compared, say, to extensive up front design, which really isn't very often
applicable. :)

So we have ten thousand things that among us we all know. Some of them are
explicitly named in XP. Some of them go well with XP in this or that
situation; some do not. We pull these tricks from the bag in accord with
our experience, our reading, our conversations with each other. Sometimes
we even make up a new one.

There's an art to picking one of these practices in the right place and
time. In general, I think, we'd rather need to recommend nothing: the team
would just be doing the right things, using their own intuition, not ours.

When people are given a list of practices, a common mistake is that they
decide they are supposed to do them all. Thus RUP people often do a million
things, even though RUP clearly states that you have to create a specific
case for your project. Same for CMM: it clearly states that it should be
customized, yet a common response is to pile on the practices. Beck
cleverly took advantage of this tendency people have by making all the XP
practices "mandatory".

Practices are like patterns, in that they are applied in response to the
```

1 May 2004 14:24

### How do you eat an elephant?

```Dear all,

There is a "big" project (initial estimation:  about 40 weeks long
with around 20 programmers)

Requirements are already documented largely in paper.
The schedule is very tide.

The system is so large that people cannot believe in that we cannot
begin coding before designing all the system. (We cannot afford big
refactorings during the project, to minimize this, all the system
should be designed at the beginning.)

If you think in terms of XP pratices only, it seems a very valid
claim saying it is less risky to begin the programming after
designing all the system.

The question is:
1.  Do you think whether XP practices (namely, simple design) can be
applied to this project?

2.  Do you believe in that Object Oriented Design (OOD) gives XP
pratices the power that although the whole system is not designed at
the beginning thanks to OOD it is possible to begin small (without
designing the whole system but at the same time no anourmous
refactoring will be required during the project?

3.  How about performing XP without OOD - do you think it is still
economic (preferable) compared to waterfall.

```

1 May 2004 15:08

### Re: How do you eat an elephant?

```> From: "Orhan Kalayci"
<orhan.kalayci.at.nitelik.net <at> yahoogroups.at.jhrothjr.com>
> Sent: Saturday, May 01, 2004 8:24 AM
> Subject: [XP] How do you eat an elephant?

One bite at a time.

> Dear all,

> There is a "big" project (initial estimation:  about 40 weeks long
> with around 20 programmers)

That's too many developers for one team. You need to
split the project into two or more subsystems, so that you
have between three and ten (or so) developers on each one.

> Requirements are already documented largely in paper.
> The schedule is very tight.

of "complete" requirements? In other words, how
much change do you expect, based on past experiance,
in the requirements as the project progresses. That isn't
just "major" change that's covered with a formal change
request, but minor clarifications of incomplete, conflicting
or imprecise requirements?

> The system is so large that people cannot believe in that we cannot
> begin coding before designing all the system. (We cannot afford big
> refactorings during the project, to minimize this, all the system
```

1 May 2004 15:11

### Re: How do you eat an elephant?

```On Saturday, May 1, 2004, at 8:24:46 AM, Orhan Kalayci wrote:

> There is a "big" project (initial estimation:  about 40 weeks long
> with around 20 programmers)

The first XP project was over 200 weeks, with 14 programmers ... over 50
weeks before the first commercial deployment.

> Requirements are already documented largely in paper.
> The schedule is very tide.

> The system is so large that people cannot believe in that we cannot
> begin coding before designing all the system. (We cannot afford big
> refactorings during the project, to minimize this, all the system
> should be designed at the beginning.)

People shouldn't do what they don't believe in. On the other hand, up front
design is not the only way, or even the best way, to avoid large
refactorings.

> If you think in terms of XP pratices only, it seems a very valid
> claim saying it is less risky to begin the programming after
> designing all the system.

It doesn't seem valid to me. How many weeks of the 40 do people propose to
spend designing all the system? How many of the team of 20 will do this?

> The question is:
> 1.  Do you think whether XP practices (namely, simple design) can be
> applied to this project?
```

1 May 2004 15:47

### RE: Re: DSDM is Agile

```Using a non-disclosure agreement to inhibit communication would seem to be a first-order violation of the
agile manifesto ("collaboration over contract negotiation").  Making methodologies proprietary is no
way to facilitate learning from each other.

On Saturday, May 1, 2004, at 5:43:26 AM, rachelclairedavies wrote:

> I would like to fill in some more background info because I feel
> that, as I provided advice on XP to the DSDM consortium for DSDM
> v4.2 in 2002/2003, I am implicated in the choice of Enterprise XP
> name. During this time I was bound by a non-disclosure agreement so
> I could not discuss freely on this list. At this time another XP
> advisor on DSDM v4.2, Sean Hanly, expressed within the review
> group "I personally am uncomfortable with EnterpriseXP tag and would
> prefer that we disassociate the 4.2 work and EnterpriseXP." I think
> this was the general view taken by all XP practitioners who worked
> on v4.2 but DSDM consortium went ahead with the name anyhow.
> To reiterate previous mails, I have used some DSDM techniques in
> conjuntion with XP and believe that we have things to learn from
> each other but do not like "EnterpriseXP" branding.

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

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com