headers
Dale Emery | 1 May 2004 01:56
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Abbott | 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
>
>ad-free courtesy of objectmentor.com 
>Yahoo! Groups Links
>
>
>
> 
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Wake | 1 May 2004 06:09
Picon
Favicon

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

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:
     extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
rachelclairedavies | 1 May 2004 11:43
Picon

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ron Jeffries | 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ron Jeffries | 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Orhan Kalayci | 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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
yahoogroups | 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.

What is your experiance to date on the adequacy
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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ron Jeffries | 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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Gordon | 1 May 2004 15:47
Picon
Favicon

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

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |

Gmane