The Irony of Extreme Programming
Ron Jeffries 
04/12/2004 

  The irony of Extreme Programming is that while detractors continue
to  explain why it cannot work, software developers all over the world
are having success with it.

  http://www.xprogramming.com/xpmag/jatIronyOfXP.htm

Enjoy ...

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries wrote:

> The Irony of Extreme Programming
> Ron Jeffries
> 04/12/2004
>
>   The irony of Extreme Programming is that while detractors continue
> to  explain why it cannot work, software developers all over the world
> are having success with it.
>
>   http://www.xprogramming.com/xpmag/jatIronyOfXP.htm

If they all posted here, they'd drown out the dissent (the same way the
occassional troll gets drowned out on the XP mailing list).

They don't post here, because of the detractors.

-- 
  Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

Phlip:

> They don't post here, because of the detractors.

I'm not sure about "detractors", per se. It's just Usenet. I was quite 
leery of posting anything here at first, and I'm still not convinced the 
forum works, in the sense of drawing out the best ideas from all.

Laurent
http://bossavit.com/thoughts/

On Mon, 12 Apr 2004 08:13:04 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
> The irony of Extreme Programming is that while detractors continue to
> explain why it cannot work, software developers all over the world are
> having success with it.

I think you have to prove it, because it is just a statement. Have you maybe
done a research survey or something like this? Where are the figures I can
check?

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

On Mon, 12 Apr 2004 16:20:02 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>On Mon, 12 Apr 2004 08:13:04 -0400, Ronald E Jeffries <ronjeffries@acm.org>
>wrote:
>> The irony of Extreme Programming is that while detractors continue to
>> explain why it cannot work, software developers all over the world are
>> having success with it.
>
>I think you have to prove it, because it is just a statement. Have you maybe
>done a research survey or something like this? Where are the figures I can
>check?

With all due respect, Sebastian, I don't have to prove it. You don't
have to believe it without a research survey or figures, however.
That's OK.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 12 Apr 2004 13:52:26 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
>>I think you have to prove it, because it is just a statement. Have you maybe
>>done a research survey or something like this? Where are the figures I can
>>check?
>
> With all due respect, Sebastian, I don't have to prove it.

Right, but how would you try to confince me if you don't prove it? I might
think you can't prove it, it is just marketing talk...

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

"Sebastian Stein" <seb_stein@gmx.de> wrote in message
news:1q6rk1-pt1.ln1@laptop-seb.hpfsc.de...
> On Mon, 12 Apr 2004 13:52:26 -0400, Ronald E Jeffries
<ronjeffries@acm.org>
> wrote:
> >>I think you have to prove it, because it is just a statement. Have you
maybe
> >>done a research survey or something like this? Where are the figures I
can
> >>check?
> >
> > With all due respect, Sebastian, I don't have to prove it.
>
> Right, but how would you try to confince me if you don't prove it? I might
> think you can't prove it, it is just marketing talk...

You can belive what you want. You cannot, however,
control the results of holding that belief.

John Roth
>
> Sebastian
> -- 
> http://www.hpfsc.de/ - die Seite rund um:
> Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
> Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

On Mon, 12 Apr 2004 16:16:29 +0200, Laurent Bossavit
<laurent@dontspambossavit.com> wrote:

>Phlip:
>
>> They don't post here, because of the detractors.
>
>I'm not sure about "detractors", per se. It's just Usenet. I was quite 
>leery of posting anything here at first, and I'm still not convinced the 
>forum works, in the sense of drawing out the best ideas from all.

You mean you don't think that half the bandwidth should be spent
arguing about whether it's OK to call someone an idiot?


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Mon, 12 Apr 2004 19:21:05 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>On Mon, 12 Apr 2004 13:52:26 -0400, Ronald E Jeffries <ronjeffries@acm.org>
>wrote:
>>>I think you have to prove it, because it is just a statement. Have you maybe
>>>done a research survey or something like this? Where are the figures I can
>>>check?
>>
>> With all due respect, Sebastian, I don't have to prove it.
>
>Right, but how would you try to confince me if you don't prove it? I might
>think you can't prove it, it is just marketing talk...

If you're interested, you'll look into it. If you want to know more,
you'll ask me questions and assess what I say. If you aren't
interested, I have no current need to try to turn you in a different
direction. You're a smart lad, you'll learn things that are useful to
you.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

>>> I think you have to prove it, because it is just a statement.
>>> Have you maybe done a research survey or something like this?
>>> Where are the figures I can check?

> --- Ronald E Jeffries <ronjeffries@acm.org> wrote:
>> With all due respect, Sebastian, I don't have to prove it.

--- Sebastian Stein <seb_stein@gmx.de> wrote...
> Right, but how would you try to convince me if you don't prove it?
> I might think you can't prove it; it is just marketing talk...

Scientific studies are not the only way to demonstrate the
effectiveness of a technique sufficiently for one to make a rational
and well-informed business decision.  In fact, remarkably few business
decisions are made based on the "proven" results of scientific
studies.  Also, some scientific studies produce invalid results.

Good business decisions can be based on a number of things.
Including...

1. Trying it, and observing how well it works (or not).

2. Observing others doing it.  Visit a team using the technique (or
tool); watch them; talk to them.

3. Talk to people who have used various techniques (or tools).  Ask
them how well they worked.

Metrics and numbers are valuable, when you can get them.  But full
double-blind scientific studies are expensive and time-consuming. 
Their cost may not be justified based on the reduction in risk they
may provide for your business decisions.

I think that extreme programming, being a light-weight framework, lets
good people to do good work. Calling the techniques "extreme" is a
good marketing gimmick, but I don't think there is really anything so
extreme about them. Extreme programming is basically an approach
grounded in common sense: The quality of the people doing the work
matters more than any methods you employ; make sure your
customer/sponsor stays in the loop; test your work and automate those
tests so you have some well defined way to know you application
continues to work as you make changes to it over time; keep your
product in a functional state as you add features; work in short
iterations so your work demonstrates visible progress; keep the
channels of communication open, etc... Perhaps some people's doubts
about extreme programming stem from the very marketing gimmick that
made it popular. While scientific studies to measure the effectiveness
of XP teams ought to continue being done, it seems fairly obvious to
me that extreme programming can't really be a bad thing. Perhaps
another problem is that people believe an all-encompassing process
will yield good results under all conditions. It seems self-evident to
me, with the experience in the industry I've had, that this is simply
impossible. You have to have good people with a can-do, cooperative
attitude (including the management and the customers/sponsors).

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<is1l70h0hjpa6ik7lhks99u40s12hiblmt@4ax.com>...
> The Irony of Extreme Programming
> Ron Jeffries 
> 04/12/2004 
> 
>   The irony of Extreme Programming is that while detractors continue
> to  explain why it cannot work, software developers all over the world
> are having success with it.
> 
>   http://www.xprogramming.com/xpmag/jatIronyOfXP.htm

Sebastian Stein wrote:

> I think you have to prove it, because it is just a statement. Have you
maybe
> done a research survey or something like this? Where are the figures I can
> check?

He has witnessed the odds someone detracts goes down as they try a project
for themselves.

-- 
  Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

On Mon, 12 Apr 2004 16:28:30 -0400, John Roth <newsgroups@jhrothjr.com>
wrote:
> You can belive what you want. You cannot, however,
> control the results of holding that belief.

I'm not talking about believe. I'm talking about knowledge. Of course you
can not prove a belief - it is impossible e.g. to prove god exists or not.
XP is not a religion I think, so it must be possible to build a prove or at
least some kind argumentation line, why it should work.

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

Jeff ,

> Scientific studies are not the only way to demonstrate the
> effectiveness of a technique sufficiently for one to make a rational
> and well-informed business decision.  In fact, remarkably few business
> decisions are made based on the "proven" results of scientific
> studies.  Also, some scientific studies produce invalid results.

It is unfortunate that there are some scientific studies that produce
invalid results, but this is the reality.  However, there are many, many
more personal anecdotes that propitiate invalid results.  I selected that
word "propitiate" because it means to gain or regain the favor or goodwill
of ...  Humans consistently support ideas and notions that benefit
themselves, but are suboptimal for those around them.  Without measurement
and study, those benefits can not be compared to anything and therefore have
no basis.  This adds very little value to our profession.  It leads to
arguments like:

Person 1: I have metrics that show when two experienced programmers pair,
they produce the same amount of work product that an individual experienced
programmer produces.

Person 2: You can't measure that.

Person 1: I did.

Person 2: Well you can't.  It's apples and oranges.

Person 1: So why don't you measure it.

Person 2: Because you can't measure it.

Person 1: How do you know you can't measure it and that it's apples and
oranges?  Why don't you just try?

Person 2: Because it can't be measured.

> Good business decisions can be based on a number of things.

Good business decisions are always based on past performance data, sound
experience and some prediction of the future.  To the degree that these
three elements are missing, one has to rely only on luck.  When one relies
on luck, it's at best a 50/50 proposition; sometimes right and some times
wrong.

> Including...
>
> 1. Trying it, and observing how well it works (or not).
>
> 2. Observing others doing it.  Visit a team using the technique (or
> tool); watch them; talk to them.
>
> 3. Talk to people who have used various techniques (or tools).  Ask
> them how well they worked.
>
> Metrics and numbers are valuable, when you can get them.  But full
> double-blind scientific studies are expensive and time-consuming.

The old, can't measure it agrument!  If I could offer a $10,000,000.00 for a
project to measure the performance of XP, I assume there are many who would
compete to win that project.  Since I don't have the $10,000,000.00 to
offer, I will offer one big challenge.  I challenge every XP enthusiast to
measure and document the cost and benefit of XP in a professional software
development team -- consider it the greatest Open Source project ever and do
it.

As much as I enjoy unit-testing and pair-programming, my data shows that
there is a tradeoff between the quality of code (increases) and the number
of features delivered (decreases).  The bad news for all those making
business decisions is that quite often it takes a lot of code quality to
balance against a small number of delivered features.  You may not like to
hear that, but this is the reality.

> Their cost may not be justified based on the reduction in risk they
> may provide for your business decisions.

Software development is expensive.  Enough measurement can be done to
identify the costs and benefits, expecially when considering how much money
XP enthusiasts quote is being lost by not using XP.  Furthermore,
professionals should be able to analyze their processes and identify the
costs and benefits.  I dare you!

Regards,

Randy

On 12 Apr 2004 19:28:56 -0700, Jeff Grigg <jgrigg@mo.net> wrote:
> Scientific studies are not the only way to demonstrate the
> effectiveness of a technique sufficiently for one to make a rational
> and well-informed business decision.  In fact, remarkably few business
> decisions are made based on the "proven" results of scientific
> studies.

Can you give a percentage value of all remarkably business decisions, who
are not based on scietific studies or theories?

Nevertheless, I don't want to stress this point, you may be right, that
people make good business decisions by their feeling and not based on some
fancy theories. But, and now the big but, you can explore such decisions and
try to understand why they are so remarkable. Let's say XP has shown a great
benefit in software projects. Now I ask, why? Why do the application of the
XP principles improve software development? If we understand the reasons, we
can maybe improve XP further more.

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

On Mon, 12 Apr 2004 21:56:38 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
> If you're interested, you'll look into it. If you want to know more,
> you'll ask me questions and assess what I say. If you aren't
> interested, I have no current need to try to turn you in a different
> direction. You're a smart lad, you'll learn things that are useful to
> you.

Let me rewrite your initial statement to another notation:

Thesis: Software development can be greatly improved
Condition: by applying XP (described e.g. in "Extreme Programming Explained.
Embrace Change" by K. Beck, 2000)
Prove/Explenation: ???

Suppose you are a consultant selling for example XP training sessions. I'm a
manager of a software production company. You want my money. So you made the
offer to me to improve my software production by applying XP. I ask you to
explain me, why those XP principles should work. I may also ask you what is
meant by "improve software development". Will the software quality be
better, the costs lower and the production faster (better schedules)?

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

Randy:

> As much as I enjoy unit-testing and pair-programming, my data shows that
> there is a tradeoff between the quality of code (increases) and the number
> of features delivered (decreases).

There are two hypotheses that could explain this. One is that these 
teams spend more time on quality, and thus have less time to add 
features.

A different hypothesis is that the better teams are those who ship 
better code *and* less complex software, with more of the features users 
actually want and none that they don't want - translating into fewer 
features overall.

Data is good, but it's only data; the hard work is determining whether 
the data actually supports your hypotheses. Worse, data is usually 
theory-laden; research motivated by opposite purposes will often turn up 
data supporting opposite conclusions.

Worst of all, *performance* data often has side-effects detrimental to 
what it is supposed to measure. Cf. Robert Austin's /Measuring and 
Managing Performance in Organizations/.

Laurent
http://bossavit.com/thoughts/

On Tue, 13 Apr 2004 05:57:51 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>On Mon, 12 Apr 2004 16:28:30 -0400, John Roth <newsgroups@jhrothjr.com>
>wrote:
>> You can belive what you want. You cannot, however,
>> control the results of holding that belief.
>
>I'm not talking about believe. I'm talking about knowledge. Of course you
>can not prove a belief - it is impossible e.g. to prove god exists or not.
>XP is not a religion I think, so it must be possible to build a prove or at
>least some kind argumentation line, why it should work.

I'll be happy to explain why it works -- or my opinion on why it
works. Was there somewhere you'd like to start?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 13 Apr 2004 06:14:03 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>Let me rewrite your initial statement to another notation:
>
>Thesis: Software development can be greatly improved
>Condition: by applying XP (described e.g. in "Extreme Programming Explained.
>Embrace Change" by K. Beck, 2000)
>Prove/Explenation: ???

This is not equivalent to my initial statement, as I'm sure you are
aware. Just wanted to note that ...
>
>Suppose you are a consultant selling for example XP training sessions. I'm a
>manager of a software production company. You want my money. So you made the
>offer to me to improve my software production by applying XP. I ask you to
>explain me, why those XP principles should work. I may also ask you what is
>meant by "improve software development". Will the software quality be
>better, the costs lower and the production faster (better schedules)?

I am a consultant, and selling is, perhaps unfortunately, what I do
not do. What I do is to provide training and coaching to people who
ask for it. 

I also produce hundreds of pages of information every year on what XP
is, how to do it, how it works, and the like. From time to time,
people run across this information, think it might be interesting, and
contact me. This is more like marketing than it is like selling. It's
probably not even very good marketing, but so far I manage to survive.
:)

I have talks of various lengths, elevator length, one hour, half day,
and so on, describing what XP is and why it works. I try only to give
those to people who might be interested. 

As it happens, the answers to your last questions are

  Yes, XP teams almost uniformly report that the quality they produce
is better than what they themselves produced before. The reason why
this happens, in my opinion, is that generally they improve two
practices which are central to quality: good testing, and good,
continuous, design improvement.

  Yes, XP teams generally report lower cost for producing software
than they had before. The reasons, in my opinion, include better focus
on what is really needed (On-site Customer, Planning Game, Small
Releases), higher quality (more testing, less debugging), and keeping
the code flexible (Design Improvement, Refactoring).

  Yes, XP teams generally have better schedules than they had before,
owing to the practice of breaking features down into smaller bits,
estimating all of them, and tracking velocity. This induces better
business decisions about which features to include and which ones to
defer.

  Yes, XP teams generally produce features faster than they had
before, owing primarily to higher quality (see above) and to better
teamwork with their customers and with each other.


I don't know whether there might be something better than XP: I've
never seen a head-to-head comparison. I do know that every team I've
worked with, or heard of, that tried XP practices found that their
situation improved in terms of quality, cost, and schedule.

Are there other ways to improve? Surely. Is this one? Surely.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 13 Apr 2004 00:05:35 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>As much as I enjoy unit-testing and pair-programming, my data shows that
>there is a tradeoff between the quality of code (increases) and the number
>of features delivered (decreases).  The bad news for all those making
>business decisions is that quite often it takes a lot of code quality to
>balance against a small number of delivered features.  You may not like to
>hear that, but this is the reality.

I produce better code and more features when paired. Might just be me.
Might be something we're doing differently.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 13 Apr 2004 06:06:15 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>On 12 Apr 2004 19:28:56 -0700, Jeff Grigg <jgrigg@mo.net> wrote:
>> Scientific studies are not the only way to demonstrate the
>> effectiveness of a technique sufficiently for one to make a rational
>> and well-informed business decision.  In fact, remarkably few business
>> decisions are made based on the "proven" results of scientific
>> studies.
>
>Can you give a percentage value of all remarkably business decisions, who
>are not based on scietific studies or theories?

In twenty years at ComShare, I saw thousands of business decisions
made, and not one of them ever was based on scientific data or
scientific theory.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

>>--- Jeff Grigg wrote:
>>> Scientific studies are not the only way to demonstrate the
>>> effectiveness of a technique sufficiently for one to make a
rational
>>> and well-informed business decision.  In fact, remarkably few
business
>>> decisions are made based on the "proven" results of scientific
>>> studies.

> --- Sebastian Stein <seb_stein@gmx.de> wrote:
>> Can you give a percentage value of all remarkably business
decisions, who
>> are not based on scietific studies or theories?

Ronald E Jeffries <ronjeffries@acm.org> wrote...
> In twenty years at ComShare, I saw thousands of business decisions
> made, and not one of them ever was based on scientific data or
> scientific theory.

I was thinking the same thing.  I've been in the business for over 20
years, and my father and I have had many talks about his business
experiences.  I've made quite a few business decisions, and seen many
made.  I can't recall ever hearing of any business decision made with
any significant input of hard scientific data.

So I'd have to put the number at "below 1%" -- probably some orders of
magnitude below.


On the other hand, I happen to have heard, from reliable sources,
about multi-million dollar business decisions made based on casual
conversation on the golf course, and those based on trinkets
(notepads, pens, etc) left by salesmen.  (Not to mention outright
bribes and sexual relations; unfortunate, but they do happen.)

Personally, I'm generally happy to see decent numbers, when we can get
them.  But even many of the "hard and fast numbers" I see are very
shaky.  What's the objective value of sending Debbie to a SQL class,
to improve her ability to do ad-hoc reports?  I'm a firm believer that
this value can be expressed in dollars.  But computing this value can
be a bit tricky.

On Tue, 13 Apr 2004 05:43:03 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
>>Thesis: Software development can be greatly improved
>>Condition: by applying XP (described e.g. in "Extreme Programming Explained.
>>Embrace Change" by K. Beck, 2000)
>>Prove/Explenation: ???
>
> This is not equivalent to my initial statement, as I'm sure you are
> aware. Just wanted to note that ...

Yes, I know, but maybe with some minor modification I think you could
support it. Maybe remove the "greatly" in the thesis.
You said you have no surveys to support your statement about developers
having success by applying XP. I didn't want to stress this point, so I
modified the thesis.

>   Yes, XP teams almost uniformly report that the quality they produce
> is better than what they themselves produced before. The reason why
> this happens, in my opinion, is that generally they improve two
> practices which are central to quality: good testing, and good,
> continuous, design improvement.

Yes, I would support this. Even more you can say, writing test cases is
doing design.

>   Yes, XP teams generally report lower cost for producing software
> than they had before. The reasons, in my opinion, include better focus
> on what is really needed (On-site Customer, Planning Game, Small
> Releases), higher quality (more testing, less debugging), and keeping
> the code flexible (Design Improvement, Refactoring).

I can go with that argument as well. It would be interesting if developing
an application with the same feature set is cheaper to be produced in XP in
comparision to another classical method.

>   Yes, XP teams generally have better schedules than they had before,
> owing to the practice of breaking features down into smaller bits,
> estimating all of them, and tracking velocity. This induces better
> business decisions about which features to include and which ones to
> defer.

There might be a danger. By just estimating the small pieces and suming it
up, you will get a too low estimation I think.

>   Yes, XP teams generally produce features faster than they had
> before, owing primarily to higher quality (see above) and to better
> teamwork with their customers and with each other.

Here I must ask why they produce features faster? I don't mean they can start
producing features earlier, because of the non-existing analysis and design
steps. Can 2 people doing pair-programming produce more features in the same
time then 2 seperated developers? I am not sure about it.

Sebastian
-- 
http://www.halle-ist-schoen.de/
Bilddokumentation der schoensten Saalestadt

>
> Let me rewrite your initial statement to another notation:
>
> Thesis: Software development can be greatly improved
> Condition: by applying XP (described e.g. in "Extreme Programming
Explained.
> Embrace Change" by K. Beck, 2000)
> Prove/Explenation: ???
>
> Suppose you are a consultant selling for example XP training sessions. I'm
a
> manager of a software production company. You want my money. So you made
the
> offer to me to improve my software production by applying XP. I ask you to
> explain me, why those XP principles should work. I may also ask you what
is
> meant by "improve software development". Will the software quality be
> better, the costs lower and the production faster (better schedules)?
>

XP is not a product to sell,
XP is a choice to be made by the team of developpers

imho there is nothing to prove, dev try it or not, adopt it or not,
but it's a dev choice not a management choice

zwetan

"Randy A. Ynchausti" <randy_ynchausti@msn.com> wrote in message
news:407b849d$1@news.totallyobjects.com...
> Jeff ,
>
> > Scientific studies are not the only way to demonstrate the
> > effectiveness of a technique sufficiently for one to make a rational
> > and well-informed business decision.  In fact, remarkably few business
> > decisions are made based on the "proven" results of scientific
> > studies.  Also, some scientific studies produce invalid results.
>
> It is unfortunate that there are some scientific studies that produce
> invalid results, but this is the reality.  However, there are many, many
> more personal anecdotes that propitiate invalid results.  I selected that
> word "propitiate" because it means to gain or regain the favor or goodwill
> of ...  Humans consistently support ideas and notions that benefit
> themselves, but are suboptimal for those around them.  Without measurement
> and study, those benefits can not be compared to anything and therefore
have
> no basis.  This adds very little value to our profession.  It leads to
> arguments like:
>
> Person 1: I have metrics that show when two experienced programmers pair,
> they produce the same amount of work product that an individual
experienced
> programmer produces.
>
> Person 2: You can't measure that.

There's a fallacy here that I'm going to deal with in
another post. In this one...

[...]

Let's talk about measurement for a minute.
There's a school of thought that goes: "If you can't measure
it, you don't know what you're talking about."

When you get into measurement, you need to remember that
every measurement has two qualities: precision and accuracy.

If you ask what time it is, and I look out the window, see the
sun is up and reply "daytime," that's a measurement. It has one
bit of precision and one bit of accuracy. (It's probably not all
that useful to you, either, but this is a tutorial, not the real world.)

For the same question, if I look out the window and see where
the shadow cast by the flagpole is, and reply: "12:32 and 46
seconds", that measurement has somewhere around 18 bits
of precision and probably around 4 or 5 bits of accuracy - if
that.

In fact, every statement of observation is a meaurement with
a quantifiable precision and accuracy. I cannot say "blue"
without making a quantifiable statement about color, saturation
and luminance. Of course, both the accuracy and precision
of that statement are rather low.

So let's take a real world question: "how close is this project
to completion? (ignoring risk factors for the moment.) Let's
assume that we have a deliverable in three months, and we're
comparing XP and a typical plan-driven approach (*not*
monolithic waterfall).

XP will deliver the product in 13 one week increments, while
the plan driven approach will deliver at the end of the three
months. The plan-driven project manager can, of course,
always get an answer from his Microsoft Project plan, based
on status reports and so forth.

The plan-driven approach will produce more precise
measurement, but the XP approach will produce more
accurate measurements.

Why? At the end of every week, the XP team will deliver
a production quality, installable product that passes the defined
acceptance tests for more features than the previous week.
That's a measurement that has both accuracy and precision.

The plan-driven manager does not have that measurement
until near the end of the project when everything has been
integrated and acceptance testing has started. All the intermediate
measures have a degree of uncertainty because they involve
intermediate products that either haven't been tested, or
haven't been tested in their final configuration.

This is not to say that the plan-driven project manager's
estimates are completely inaccurate. A competent project
manager has a reasonably good appreciation of how much
of what's been done will have to be reworked once it's been
through the next level of verification and testing.

So let's look at risk factors. There are basically two:
1) Are there unanticipated integration problems?
2) Do the requirements actually meet the customer's needs?

I'm going to ignore the first because it's not unique to
either XP or plan-driven approaches. Both processes
take similar approaches: identify risks and move them
up front where we can assess them.

XP is the clear winner here, since the customer can take
the intermediate products out and test drive them. He
can't do that with the plan-driven project because there
is no intermediate product to test drive.

That's a measurement win, right there.

John Roth

>
> Regards,
>
> Randy
>
>

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<rtcn70l1nkp5cncbhlu6cr64c0uvi7a2es@4ax.com>...

> >Thesis: Software development can be greatly improved
> >Condition: by applying XP (described e.g. in "Extreme Programming Explained.
> >Embrace Change" by K. Beck, 2000)
> >Prove/Explenation: ???
> 
> This is not equivalent to my initial statement, as I'm sure you are
> aware. Just wanted to note that ...

And an essential part of the story is missing.

Consider:
- software can be made faster by implementing in Smalltalk.
- software can be made faster by implementing in Smalltalk, instead of
interpreted Basic.
- software can be made faster by implementing in Smalltalk, instead of
compiled Ada.


"Software development can be greatly improved by applying XP"
implicitly assumes that we are comparing XP with some 'other way of
developing software'.

Once we've identified that 'other way of developing software' we can
begin to wonder about the assertion, until then...

On 13 Apr 2004 08:34:50 -0700, Isaac Gouy <igouy@yahoo.com> wrote:
> Once we've identified that 'other way of developing software' we can
> begin to wonder about the assertion, until then...

Right, with the other way I meant a classical method used today.

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<opll7050qnelf46n21q8b8llup0234h8m1@4ax.com>...

> >> The irony of Extreme Programming is that while detractors continue to
> >> explain why it cannot work, software developers all over the world are
> >> having success with it.
> >
> >I think you have to prove it, because it is just a statement. Have you maybe
> >done a research survey or something like this? Where are the figures I can
> >check?
> 
> With all due respect, Sebastian, I don't have to prove it. You don't
> have to believe it without a research survey or figures, however.

Quite so, it's a question of role.
Ron has taken the role of XP promoter.
  
Horrible to imagine, but developers all over the world also have
success - whatever that means - with something other than XP.

Wondering whether there's more or less success, and why that might be,
is not the role of a promoter or a detractor.

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404130734.390ef345@posting.google.com...
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
news:<rtcn70l1nkp5cncbhlu6cr64c0uvi7a2es@4ax.com>...
>
>
> "Software development can be greatly improved by applying XP"
> implicitly assumes that we are comparing XP with some 'other way of
> developing software'.
>
> Once we've identified that 'other way of developing software' we can
> begin to wonder about the assertion, until then...

Speaking broadly, there are only four general approaches
in use today: code and fix, monolithic waterfall, plan driven
and agile.

I don't think anyone is going to dispute the proposition that
XP is going to be an improvement over both code and fix and
monolithic waterfall. So the issue is XP versus plan-driven.

John Roth

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<9jdn70hlgej0smde9igb65uq2e3s7fcjee@4ax.com>...

> I produce better code and more features when paired. 

And you know that because you've measured the quality of code and
number of features, you & your pair produce, with and without pairing?

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404130750.2cedbc2f@posting.google.com...
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
news:<opll7050qnelf46n21q8b8llup0234h8m1@4ax.com>...
>
> > >> The irony of Extreme Programming is that while detractors continue to
> > >> explain why it cannot work, software developers all over the world
are
> > >> having success with it.
> > >
> > >I think you have to prove it, because it is just a statement. Have you
maybe
> > >done a research survey or something like this? Where are the figures I
can
> > >check?
> >
> > With all due respect, Sebastian, I don't have to prove it. You don't
> > have to believe it without a research survey or figures, however.
>
> Quite so, it's a question of role.
> Ron has taken the role of XP promoter.
>
> Horrible to imagine, but developers all over the world also have
> success - whatever that means - with something other than XP.
>
> Wondering whether there's more or less success, and why that might be,
> is not the role of a promoter or a detractor.

No, but it does beg the question of whether you've done
your homework.

As I said in another post, there are, broadly speaking, only
four methodologies in widespread use: code and fix, monolithic
waterfall, plan-driven and agile. They will all work within
boundaries.

Code and fix will work on a single developer project of less
than a half developer-year that has relatively static requirements
and a competent developer.

Monolithic waterfall will work for projects with an experienced
project manager with stable requirements, a final delivery date
of six months or less and a relatively small team of competent
developers.

Neither scales worth s--t, and neither has any significant tolerance
for requirements instability.

Plan driven methodologies work well on any scale project
given a relatively stable set of requirements, experienced
project management and reasonably competent developers.

Agile methodologies also work on any scale project (although
"by the book XP" doesn't scale) and have a much larger tolerance
for requirements instability. Martin Fowler has an interesting
comment http://martinfowler.com/bliki/VeryLowDefectProject.html
about the possibility of using XP and getting very low defect rates.

As a parting note, have you read "Lean Software Development",
by Mary and Tom Poppendieck? While they don't single out any
particular development methodology, they do give a set of tools
that you can use to find the waste in the popular ones.

John Roth

"John Roth" <newsgroups@jhrothjr.com> wrote...
> Let's talk about measurement for a minute. [...]
> 
> When you get into measurement, you need to remember that
> every measurement has two qualities: precision and accuracy.

Let's also consider /relevance/.

Let's say that my project cost $12,672.43 last month.  Let's suppose
that this is an accurate and precise figure.

That's nice, but it doesn't help me much with decisions like,
 "Should I do more or less xUnit testing?" or
 "Should I do more or less Pair Programming?"

> >   Yes, XP teams generally have better schedules than they had before,
> > owing to the practice of breaking features down into smaller bits,
> > estimating all of them, and tracking velocity. This induces better
> > business decisions about which features to include and which ones to
> > defer.
>
> There might be a danger. By just estimating the small pieces and suming it
> up, you will get a too low estimation I think.

An XP team doesn't only estimate the small pieces, it also measures how fast
they actually develop that small pieces and use that data to extrapolate for
the features still to implement.


> >   Yes, XP teams generally produce features faster than they had
> > before, owing primarily to higher quality (see above) and to better
> > teamwork with their customers and with each other.
>
> Here I must ask why they produce features faster? I don't mean they can
start
> producing features earlier, because of the non-existing analysis and
design
> steps. Can 2 people doing pair-programming produce more features in the
same
> time then 2 seperated developers? I am not sure about it.

Implementing a feature is creative work. Often with one flash of wit you can
save hours of work. That's more likely to happen when you allow team members
to inspire each other.

Well, that's only part of why it works. I find it somewhat hard to explain
it, but I know that it works, because I am doing it. :)

Cheers, Ilja

> XP is not a product to sell,
> XP is a choice to be made by the team of developpers

Very well said, very well said...

Cheers, Ilja

"Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0404130943.57d74f1f@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote...
> > Let's talk about measurement for a minute. [...]
> >
> > When you get into measurement, you need to remember that
> > every measurement has two qualities: precision and accuracy.
>
> Let's also consider /relevance/.
>
> Let's say that my project cost $12,672.43 last month.  Let's suppose
> that this is an accurate and precise figure.
>
> That's nice, but it doesn't help me much with decisions like,
>  "Should I do more or less xUnit testing?" or
>  "Should I do more or less Pair Programming?"

That's true, and I wrote (and deleted) a fairly long screed on
that exact point in response to one of Randy's posts.

John Roth

John, that was eye-opening - thank you very much!

Regards, Ilja

> What's the objective value of sending Debbie to a SQL class,
> to improve her ability to do ad-hoc reports?  I'm a firm believer that
> this value can be expressed in dollars.  But computing this value can
> be a bit tricky.

And even if it can be done, what's the value of an objective value?

What is the value of the improved motivation because of showing care for the
education of your employees? What is the value of Debbie getting into
contact with new people which might inspire her? What is the value of Tom's
envy because this is Debbie's second class, but he never is allowed to get
one?

I suspect the most important value of computing an objective value is the
illusion of control...

Take care, Ilja

"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107nvbm5lbn0j10@news.supernews.com>...

> There's a school of thought that goes: "If you can't measure
> it, you don't know what you're talking about."

This school of thought:
"When you can measure what you are speaking about, and express it in
numbers, you know something about it; but when you cannot measure it,
when you cannot express it in numbers, your knowledge of it is of a
meager and unsatisfactory kind; it may be the beginning of knowledge,
but you have scarcely, in your thoughts, advanced it to the stage of
science."

Sir William Thompson, Lord Kelvin (1824-1907)

On Tue, 13 Apr 2004 15:20:54 +0200, zwetan <newsgroups@zwetan.com> wrote:
>> Suppose you are a consultant selling for example XP training sessions. I'm
> a
>> manager of a software production company. You want my money. So you made
> the
>> offer to me to improve my software production by applying XP. I ask you to
>> explain me, why those XP principles should work. I may also ask you what
> is
>> meant by "improve software development". Will the software quality be
>> better, the costs lower and the production faster (better schedules)?
>
> XP is not a product to sell,

I spoke about XP training sessions. This is indeed a product, the product of
a consultant. Please read my post again and re-think!

> XP is a choice to be made by the team of developpers
>
> imho there is nothing to prove, dev try it or not, adopt it or not,
> but it's a dev choice not a management choice

Are you sure? Who is paying the developers? Who is responsible what happens
with this money?

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107o3dsgg61mffd@news.supernews.com>...

> > "Software development can be greatly improved by applying XP"
> > implicitly assumes that we are comparing XP with some 'other way of
> > developing software'.
> >
> > Once we've identified that 'other way of developing software' we can
> > begin to wonder about the assertion, until then...
> 
> Speaking broadly, there are only four general approaches
> in use today: code and fix, monolithic waterfall, plan driven
> and agile.
> 
> I don't think anyone is going to dispute the proposition that
> XP is going to be an improvement over both code and fix and
> monolithic waterfall. So the issue is XP versus plan-driven.

If, for the sake of argument, we accept the list of 4 approaches then
we still seem to be comparing a particular example of "agile" with a
general approach.

Once we've identified the particular example of "plan driven" then
we'll have made some progress. Alternatively we might choose to
compare XP and Scrum, or XP and DSDM, or ...

> >
> > XP is not a product to sell,
>
> I spoke about XP training sessions. This is indeed a product, the product
of
> a consultant. Please read my post again and re-think!

if you want to keep considering XP as a product which need promotion to be
sold
ok fine, but you miss totally the point.

the idea you have of selling "XP training sessions" is by nature wrong,
imho devs can only acquire XP by willing to, ok perharps requiring the
assitance
of an experienced XP coach, but the choice of doing XP is much more a
personnal choice of a team amongs tons of other choices.

Only the devs can forsee the potential of XP, it's like choosing OO
programming
or procedural programming for a particular project,
you evaluate the pros and cons, you choose what fit best the project.

So if something as "XP training sessions" was to be sold,
it will not be sold by clueless non-programmers salesman to a clueless
non-programmers manager,
it would be asked by the team of developper to the managment:
"hey boss we need an XP coach for XP training sessions".

But as usual programmers don't wait clueless non-programmers decision to try
new stuff,
will be XP, or anyother programming related stuff.

> > XP is a choice to be made by the team of developpers
> >
> > imho there is nothing to prove, dev try it or not, adopt it or not,
> > but it's a dev choice not a management choice
>
> Are you sure? Who is paying the developers? Who is responsible what
happens
> with this money?
>

Yeah I'm sure, why do programmers get paid ?

to do a job that only them can do because they know how to do it

It's not because anyone now can sit hours in front a computers,
that anyone can be a programmer (or
[replaceWithJobNameWhichRequireYearsToBeGoodAt] etc...).

So if management is clueless about programming they have no other choice
to trust their programmers to pick the correct programming
technic/methdology/etc...

And my personnal rule is to never ever let a non-programmer choose for me,
or my team, the way we gonna develop something, because it's failure
assured.

zwetan

A google search identifies some decent articles... I entered the following query:

+"plan driven"+"software engineering"+"agile"

Some of the results:

Balancing Plan-Driven and Agile Methods in Software Engineering Project Coursesz
Barry Boehm 1 , Dan Port 1 and A. Winsor Brown
http://www.szp.swets.nl/szp/journals/cs123187.htm

Agile and Plan-Driven Methods Oil and Water?
Barry Boehm, USC
http://www.agileuniverse.com/pdfs/agileAndPlanDrivenMethods

http://www.aw-bc.com/catalog/academic/product/0,4096,0321186125-PRE,00.html
Barry Boehm, Richard Turner
Balancing Agility and Discipline: A Guide for the Perplexed

http://www.computer.org/computer/homepage/0603/GEI/?SMSESSION=NO
Laurie Williams, Alistair Cockburn
Agile Software Development: It's about Feedback and Change

http://www.systemsguild.com/GuildSite/TDM/June2002Computer.pdf
Tom Demarco, Barry Boehm
The Agile Methods Fray

igouy@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.0404131451.393a9cb0@posting.google.com>...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107o3dsgg61mffd@news.supernews.com>...
> 
> > > "Software development can be greatly improved by applying XP"
> > > implicitly assumes that we are comparing XP with some 'other way of
> > > developing software'.
> > >
> > > Once we've identified that 'other way of developing software' we can
> > > begin to wonder about the assertion, until then...
> > 
> > Speaking broadly, there are only four general approaches
> > in use today: code and fix, monolithic waterfall, plan driven
> > and agile.
> > 
> > I don't think anyone is going to dispute the proposition that
> > XP is going to be an improvement over both code and fix and
> > monolithic waterfall. So the issue is XP versus plan-driven.
> 
> If, for the sake of argument, we accept the list of 4 approaches then
> we still seem to be comparing a particular example of "agile" with a
> general approach.
> 
> Once we've identified the particular example of "plan driven" then
> we'll have made some progress. Alternatively we might choose to
> compare XP and Scrum, or XP and DSDM, or ...

On 13 Apr 2004 15:51:50 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107o3dsgg61mffd@news.supernews.com>...
>
>> > "Software development can be greatly improved by applying XP"
>> > implicitly assumes that we are comparing XP with some 'other way of
>> > developing software'.
>> >
>> > Once we've identified that 'other way of developing software' we can
>> > begin to wonder about the assertion, until then...
>> 
>> Speaking broadly, there are only four general approaches
>> in use today: code and fix, monolithic waterfall, plan driven
>> and agile.
>> 
>> I don't think anyone is going to dispute the proposition that
>> XP is going to be an improvement over both code and fix and
>> monolithic waterfall. So the issue is XP versus plan-driven.
>
>If, for the sake of argument, we accept the list of 4 approaches then
>we still seem to be comparing a particular example of "agile" with a
>general approach.
>
>Once we've identified the particular example of "plan driven" then
>we'll have made some progress. Alternatively we might choose to
>compare XP and Scrum, or XP and DSDM, or ...

We might.  However, what I've noticed is that folks who adopt an agile
method don't really care much whether it is XP or FDD, or SCRUM.
Rather, they pick and choose from each of the methods the practices
that they think will fit them well.  Thus, I am working with a SCRUM
team that is learning TDD, I am working with an FDD team that is
learning pair programming and TDD.  I am working with an XP team that
is using sprints and backlogs from SCRUM.  

There is a blending and smearing going on that is blurring the lines
between the methods and resulting in something that is more like a
body of practical knowledge than individual and distinct methods.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Tue, 13 Apr 2004 00:05:35 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>I challenge every XP enthusiast to
>measure and document the cost and benefit of XP in a professional software
>development team -- consider it the greatest Open Source project ever and do
>it.

It is being done in many different companies and teams.  There are a
number of published reports about the effectiveness (and failures) of
XP and Agile methods.  There were two this month in Computerworld and
Business week alone.  There will be many others presented at Agile
Software Development, and XP/Agile Universe this summer.  

The evidence is out there is anyone cares to look.  And more is
accumulating all the time.  



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On 13 Apr 2004 08:58:24 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<9jdn70hlgej0smde9igb65uq2e3s7fcjee@4ax.com>...
>
>> I produce better code and more features when paired. 
>
>And you know that because you've measured the quality of code and
>number of features, you & your pair produce, with and without pairing?

Of course.  Don't you?



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Tue, 13 Apr 2004 13:13:13 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>
>>   Yes, XP teams generally have better schedules than they had before,
>> owing to the practice of breaking features down into smaller bits,
>> estimating all of them, and tracking velocity. This induces better
>> business decisions about which features to include and which ones to
>> defer.
>
>There might be a danger. By just estimating the small pieces and suming it
>up, you will get a too low estimation I think.

Why would that be the case? And what would be the effect of tracking
actual velocity of implementation and using that to project end dates,
as we suggest?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 13 Apr 2004 13:13:13 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>
>>   Yes, XP teams generally produce features faster than they had
>> before, owing primarily to higher quality (see above) and to better
>> teamwork with their customers and with each other.
>
>Here I must ask why they produce features faster? I don't mean they can start
>producing features earlier, because of the non-existing analysis and design
>steps. Can 2 people doing pair-programming produce more features in the same
>time then 2 seperated developers? I am not sure about it.

I find that for me, I produce more features paired than my pair and I
do unpaired. The experimental stats aren't clear but suggest that
paired code takes longer to write, but has fewer defects.

There is more to XP than pairing, and quality is a result of faster
understanding -- conversation instead of passing documents back and
forth; higher quality (less debugging); more flexible scheduling (team
code ownership, pairing), and probably other aspects that don't spring
to mind right this moment. 

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 13 Apr 2004 15:20:54 +0200, "zwetan" <newsgroups@zwetan.com>
wrote:

>XP is not a product to sell,
>XP is a choice to be made by the team of developpers
>
>imho there is nothing to prove, dev try it or not, adopt it or not,
>but it's a dev choice not a management choice

To really do XP requires management buyin, because of the "on-site
customer" and "customer acceptance tests" and "planning game"
practices.

That said, a team doing just the technical practices can rock.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 13 Apr 2004 08:58:24 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<9jdn70hlgej0smde9igb65uq2e3s7fcjee@4ax.com>...
>
>> I produce better code and more features when paired. 
>
>And you know that because you've measured the quality of code and
>number of features, you & your pair produce, with and without pairing?

I know it because I pay attention to how long it takes me to do
things, how much debugging I have to do, how often I'm down a rathole.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107o51qk3295ob3@news.supernews.com>...

> > Wondering whether there's more or less success, and why that might be,
> > is not the role of a promoter or a detractor.
> No

Good, we agree about that.

> but it does beg the question of whether you've done your homework.

The Waterfall model is so poorly named: Does water flow backwards up
the waterfall? Nope. Yet Royce's 1970 Waterfall model included
iteration within a phase (maybe he was thinking of whirlpools) and
stepping back to a previous phase.
From the name we might think it was the same as Benington's 1956
Stagewise model.

Anyway, by '80 V&V was vital and the Waterfall was diverted into the V
model. (Req, and Spec, and Design, linking to Test phases through Test
plans like this: http://www.informatik.uni-bremen.de/uniform/gdpa/def/def_v/V_MODEL.htm
)

With Boehm's '85 Spiral model we understood that the V model, and
prototyping, and evolutionary delivery, and incremental delivery were
different ways that this meta-model could unwind.

By '90 we would stress that these "are not the only possible models
and they are not to be followed rigidly. They are simply particular
examples" and then talk of blending prototyping with the V model with
incremental delivery, to meet the needs of a specific situation.


> Plan driven methodologies work well on any scale project
> given a relatively stable set of requirements, experienced
> project management and reasonably competent developers.

Are you saying that you know of an approach that succeeds with
inexperienced project management and incompetent developers?!


> Agile methodologies also work on any scale project (although
> "by the book XP" doesn't scale) and have a much larger tolerance
> for requirements instability. 

Seems like "by the book XP doesn't scales" contradicts "Agile... work
on any scale"?

Wouldn't a "plan driven" approach operating a one week plan have a
large tolerance for requirements instability?

On Tue, 13 Apr 2004 10:46:36 -0400, "John Roth"
<newsgroups@jhrothjr.com> wrote:

>Let's talk about measurement for a minute.

Nice, John. This needs to be an article somewhere.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 13 Apr 2004 11:27:25 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107nvbm5lbn0j10@news.supernews.com>...
>
>> There's a school of thought that goes: "If you can't measure
>> it, you don't know what you're talking about."
>
>This school of thought:
>"When you can measure what you are speaking about, and express it in
>numbers, you know something about it; but when you cannot measure it,
>when you cannot express it in numbers, your knowledge of it is of a
>meager and unsatisfactory kind; it may be the beginning of knowledge,
>but you have scarcely, in your thoughts, advanced it to the stage of
>science."
>
>Sir William Thompson, Lord Kelvin (1824-1907)

How much do you love your spouse, your kids if any, your parents?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 13 Apr 2004 08:50:50 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<opll7050qnelf46n21q8b8llup0234h8m1@4ax.com>...
>
>> >> The irony of Extreme Programming is that while detractors continue to
>> >> explain why it cannot work, software developers all over the world are
>> >> having success with it.
>> >
>> >I think you have to prove it, because it is just a statement. Have you maybe
>> >done a research survey or something like this? Where are the figures I can
>> >check?
>> 
>> With all due respect, Sebastian, I don't have to prove it. You don't
>> have to believe it without a research survey or figures, however.
>
>Quite so, it's a question of role.
>Ron has taken the role of XP promoter.

Not quite, my friend. I also help people who are interested in
improving their software development results, and I'm fairly good at
it.
>  
>Horrible to imagine, but developers all over the world also have
>success - whatever that means - with something other than XP.

Quite true. But few of them have success without doing many of the
same things, I find. And most of the ones I run into could improve in
some key areas, most often testing, and design improvement.
>
>Wondering whether there's more or less success, and why that might be,
>is not the role of a promoter or a detractor.

Perhaps not. But I do wonder, and I pay attention. What I don't do is
prove.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<1s5p70tthuh5ol4hol3vgi8043ihmghi63@4ax.com>...

> >This school of thought:
> >"When you can measure what you are speaking about, and express it in
> >numbers, you know something about it; but when you cannot measure it,
> >when you cannot express it in numbers, your knowledge of it is of a
> >meager and unsatisfactory kind; it may be the beginning of knowledge,
> >but you have scarcely, in your thoughts, advanced it to the stage of
> >science."
> >
> >Sir William Thompson, Lord Kelvin (1824-1907)
> 
> How much do you love your spouse, your kids if any, your parents?

Love is immeasurable, so software development must be immeasurable too? 
Confusion worse confounded.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<co5p70tn9c39d546e01nmubbl5juitlqbe@4ax.com>...
> On 13 Apr 2004 08:58:24 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
> 
> >Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<9jdn70hlgej0smde9igb65uq2e3s7fcjee@4ax.com>...
> >
> >> I produce better code and more features when paired. 
> >
> >And you know that because you've measured the quality of code and
> >number of features, you & your pair produce, with and without pairing?
> 
> I know it because I pay attention to how long it takes me to do
> things, how much debugging I have to do, how often I'm down a rathole.

Is "paying attention" the same as measuring and recording, or is it
more...  intuitive?

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<da5p705jqvgkde0mehu9pcmbqmra15vegn@4ax.com>...

> >> I produce better code and more features when paired. 
> >
> >And you know that because you've measured the quality of code and
> >number of features, you & your pair produce, with and without pairing?
> 
> Of course.  Don't you?

Sometimes, sometimes not.
So you have measurements for the work y'all did on Fitnesse?

Laurent,

> > As much as I enjoy unit-testing and pair-programming, my data shows that
> > there is a tradeoff between the quality of code (increases) and the
number
> > of features delivered (decreases).
>
> There are two hypotheses that could explain this. One is that these
> teams spend more time on quality, and thus have less time to add
> features.

Sorry to single your post out, Laurent, for a response.  I am not picking on
you.  Your post happened to be the first of all the responses to my post in
my browser.  I have not read a single response of the many respondents that
dealt with the point that is important to me (and I believe to every
software development team [although not to consultants]).  With the possible
exception of Ron's claim to have data that shows he delivers more
features/code when he pairs (the data I have for various developers does not
support this conclusion), although I fully support and practice the notion
of tracking one's own performance (I have been laughed at by many several
times when I posted the metrics that I track).  The point is that one has to
make a business decision.  The question to decide upon is:

How many features are equivalent to how much quality?

If you give up three features, how much quality does it take to make up for
those features?  If quality is, "Meeting the customer's expectations," then
to optimize the software development process you only need as much quality
as is required to make the customer happy.  At that point, a team should
maintain quality and focus on delivering features.  Absolute quality is a
lofty altruistic goal, but it is way beyond the mark in terms of running a
software development business.

GE had this problem several years ago.  They had the altruistic goal of
being number 1 or 2 in their product-business domain.  The problem was that
they could define the "product-business" domain in ways that guaranteed they
were 1 or 2.  Until a consultant came in and reframed their thinking, they
thought they were doing the best they could because they had the "best" goal
that any corporation could have.  User stories, unit-test and
pair-programming can be gamed the same way GE gamed their product-business
domain.  These software development practices are even more at risk without
any analytical tools and yardsticks.

You need data, experience and good forecasting to answer the business
question that I posed above for a given software development project.  From
the data I have, it is very likely that the optimal development rate is one
that includes part-time (15% - 35%) pair-programming and full-time
unit-testing.

By the way Ron, there is a much better article in meeting my earlier
challenge.

Regards,

Randy

On Tue, 13 Apr 2004 21:37:26 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
>>>   Yes, XP teams generally have better schedules than they had before,
>>> owing to the practice of breaking features down into smaller bits,
>>> estimating all of them, and tracking velocity. This induces better
>>> business decisions about which features to include and which ones to
>>> defer.
>>
>>There might be a danger. By just estimating the small pieces and suming it
>>up, you will get a too low estimation I think.
>
> Why would that be the case? And what would be the effect of tracking
> actual velocity of implementation and using that to project end dates,
> as we suggest?

As I said, I'm not sure about it. I think in XP the problem is dealt with by
the factor you multiplicate. Let's say you have 2 tasks each needing 4
hours. Now you would think a pair could implement this in one day. But after
finishing task 1, they maybe go out smoking or have to wait till they can
switch the pair. This extra time is not in the estimates. Maybe they have to
wait to get access to the integration computer (if they don't use CVS). Just
looking at the tasks, I think you would miss such breaks. Nevertheless, this
could be handled I think.

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

On Wed, 14 Apr 2004 02:29:17 +0200, zwetan <newsgroups@zwetan.com> wrote:
>> I spoke about XP training sessions. This is indeed a product, the product
> of
>> a consultant. Please read my post again and re-think!
>
> if you want to keep considering XP as a product which need promotion to be
> sold ok fine, but you miss totally the point.

I'm not sure if you are joking or really mean what you are saying.
Nevertheless, I try again to explain my thoughts to you.

> the idea you have of selling "XP training sessions" is by nature wrong,
> imho devs can only acquire XP by willing to, ok perharps requiring the
> assitance of an experienced XP coach, but the choice of doing XP is much
> more a personnal choice of a team amongs tons of other choices.

Well, think about a normal programmer and not the techie hacker. He is not
interested in developments going on in the software community. He just wants
to do his job. So he has never heard about XP or other agile methods. Now
the management and/or the development team has choosen to go with XP. He
never heard about it. Of course you can say he should read a book or scan
the internet for articles. Nevertheless, reading is one of the most
ineffective learning methods. So he would be glad to have someone explaining
the concept to him. This could be someone in the company, but it can also be
someone from outside like a consultant.

> So if something as "XP training sessions" was to be sold, it will not be
> sold by clueless non-programmers salesman to a clueless non-programmers
> manager, it would be asked by the team of developper to the managment:
> "hey boss we need an XP coach for XP training sessions".

Yes, I never said something else.

>> Are you sure? Who is paying the developers? Who is responsible what
>> happens with this money?
>>
>
> Yeah I'm sure, why do programmers get paid ?
>
> to do a job that only them can do because they know how to do it
>
> ...
>
> So if management is clueless about programming they have no other choice
> to trust their programmers to pick the correct programming
> technic/methdology/etc...

Right, the development team has to choose the technic/../.. But it is a
management task to accept the choice and implement it. A switch from a
classical development process to an agile one is a high-risk step. If you
fail you can loose a lot of money and customers. The management is
responsible for the money and not the techie developer.

Of course you can say management is just interested things getting done.
They don't care how the software is developed. But, working with XP in
development needs other contracts to your customers. At least you should fix
the on-side customer in the contract. Contracts are not a task of the
developers, it is a task of management. Also think about the tasks people do
in XP. You need a lot more programmers. Maybe some people have to switch
from an analysis and design position back to a programmer position, because
analysis and design people are not that much needed. At least right here in
Germany you have change the working contract with those people. This is,
once again, a task of management and not of the techie hacker.

To sum it up, and I really hope you can live with that, switching to XP is a
task of management and development team and not just the task of the
development team.


Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

Isaac Gouy wrote:
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
> news:<1s5p70tthuh5ol4hol3vgi8043ihmghi63@4ax.com>...
>
>>> This school of thought:
>>> "When you can measure what you are speaking about, and express it in
>>> numbers, you know something about it; but when you cannot measure
>>> it,
>>> when you cannot express it in numbers, your knowledge of it is of a
>>> meager and unsatisfactory kind; it may be the beginning of
>>> knowledge,
>>> but you have scarcely, in your thoughts, advanced it to the stage of
>>> science."
>>>
>>> Sir William Thompson, Lord Kelvin (1824-1907)
>>
>> How much do you love your spouse, your kids if any, your parents?
>
> Love is immeasurable, so software development must be immeasurable
> too?

If you can know something without objectively measuring it, perhaps there
are other things for which it can work, too?

Take care, Ilja

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404131743.54548ccd@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<107o51qk3295ob3@news.supernews.com>...
>

> > Plan driven methodologies work well on any scale project
> > given a relatively stable set of requirements, experienced
> > project management and reasonably competent developers.
>
> Are you saying that you know of an approach that succeeds with
> inexperienced project management and incompetent developers?!
>
>
> > Agile methodologies also work on any scale project (although
> > "by the book XP" doesn't scale) and have a much larger tolerance
> > for requirements instability.
>
> Seems like "by the book XP doesn't scales" contradicts "Agile... work
> on any scale"?
>
> Wouldn't a "plan driven" approach operating a one week plan have a
> large tolerance for requirements instability?

> --- "Randy A. Ynchausti" <randy_ynchausti@msn.com> wrote:
>> I challenge every XP enthusiast to measure and document the cost
>> and benefit of XP in a professional software development team --
>> consider it the greatest Open Source project ever and do it.

One needs more than just lots of raw numbers.  One needs comparable
numbers.

--- Robert C. Martin <unclebob@objectmentor.com> wrote...
> It is being done in many different companies and teams.  There are a
> number of published reports about the effectiveness (and failures) of
> XP and Agile methods.  There were two this month in ComputerWorld and
> Business week alone.  There will be many others presented at Agile
> Software Development, and XP/Agile Universe this summer.  
> 
> The evidence is out there is anyone cares to look.  And more is
> accumulating all the time.  

I posted some numbers to this list late last month:
 - project schedule reduced 30%.
 - project cost reduced by 50% to 75%.

The reduction in risk and bugs (number and severity) and improvement
in quality and maintainability were there, but I did not have metrics
for them.

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404131743.54548ccd@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<107o51qk3295ob3@news.supernews.com>...
>
>
> Are you saying that you know of an approach that succeeds with
> inexperienced project management and incompetent developers?!

Spoken with a bit of tongue in cheek - XP! There is at least
one university program where the professors prefer to use XP
for the first semester long class project, and save RUP (as an
introduction to plan driven) for the second. The reason? You can
get a running result with XP while the RUP project tends to fail
without any result. Of course, the actual code produced by the
novices should be taken out and buried...


>
> > Agile methodologies also work on any scale project (although
> > "by the book XP" doesn't scale) and have a much larger tolerance
> > for requirements instability.
>
> Seems like "by the book XP doesn't scales" contradicts "Agile... work
> on any scale"?

Agile includes Scrum, Crystal, DSDM and several others I
don't remember. Also, "by the book XP" refers to the version
defined for a single colocated team of not more than 12 developers.
There is a set of principles (Chapter 8, p 37 of the White Book) that
you can use to generate something that looks like XP for just about
any environment or size of project. I haven't seen it done (possibly
because most people don't know about the principles - they fixate
on either the values or the practices.)

> Wouldn't a "plan driven" approach operating a one week plan have a
> large tolerance for requirements instability?

That is, I think, a contradiction. What's missing is the ability
to handle the requirements backlog in a sensible fashion.
With three or four months between releases you don't
have to do any significant backlog management; with
iterations or sprints that short you need a reasonably
coherent way of managing it, which means you need
to either split requirements analysis the way Scrum and
XP do, or you need to do requirements analysis up front.

With a one week time box, you don't have the ability
to do a formal requirements analysis, get it reviewed,
approved, and then do the design, get it reviewed,
approved, and so forth. By the time you ditch all the
heavyweight aspects to get something done in one week,
you might as well be doing code and fix.

John Roth

Randy:

> Sorry to single your post out, Laurent, for a response. I am not picking on
> you.

No problem. I appreciate you for engaging. I won't pick on you, either, 
just insist on your being responsive to the points I raised. :)

> I have not read a single response of the many respondents that
> dealt with the point that is important to me (and I believe to every
> software development team [although not to consultants]).

I'd like to be responsive to your concerns, too. Before I can do that, I 
have to take issue with that last parenthetical point. Perhaps we don't 
mean the same thing by "consultant" - it's a vague and overused term - 
but when I act as advisor to a software development team, whatever 
issues matter to them are issues that matter to me. I take that to be 
part of being a good advisor, or consultant as I understand the term.

Now, to try and address your question:

> How many features are equivalent to how much quality?

There's a classic reductio ad absurdum which goes: "I can deliver a 
product with as many features as you care to name, and have it ready 
tomorrow... as long as it doesn't have to work."

I don't think you can trade off one for the other, though I will try to 
answer your question in terms of things that can be traded off for each 
other. A prior discussion on the topic is recorded here:
  http://c2.com/cgi/wiki?CommitmentToQuality

Quality is a problematic term, so the discussion may need a more precise 
context and some (at least provisional) definitions.

A software development effort consists of automating some operations 
which are relevant to some business purpose, within a finite budget in 
terms of time and money.

There are typically three consequences of "low quality": a) the 
operations which are implemented turn out not to be relevant to the 
purpose of the effort; b) the operations turn out to have been 
implemented unreliably, which jeopardizes the purpose of the effort; and 
c) during development, rework due to implementation defects delay the 
effort and cause it to exceed budget.

As far as problems a) and c) are concerned, there is no trade-off 
between quality and features. If you only deliver relevant features, and 
do not experience (unpredictably) lengthy test-and-debug cycles, then 
your project will cost less and produce more.

I can see how a trade-off situation could be constructed with respect to 
problem b). For instance, we are building a credit system which reduces 
the cost of processing an application from $100 to $10, and it might 
cost $10 million to build a system which makes one mistake every 1000 
applications, versus $1 million for one which makes one mistake every 
10. I gather such trade-offs are common in industrial processes.

One problem I see is that software bugs are rarely that straightforward. 
Rather than mess up one operation per 1000, they will quietly lurk for a 
million operations, then blow up the entire system and cause damages in 
the millions or billions of dollars. Examples include the Ariane Bug or 
the more recent Blackout Bug.

Another issue is that problems of type b) and problems of type c) are 
obviously correlated (and probably type a) as well). If you tend to have 
some bugs in production, then you have even more bugs that pop up during 
the development process, and delay it by usually unpredictable amounts.

> If you give up three features, how much quality does it take to make up for
> those features?

If you give up three features you didn't need, then overall quality will 
be higher and your costs will go down. Conversely, increased quality 
might mean shorter test-and-debug cycles, which in turn means more time 
available to implement features you do need.

> With the possible exception of Ron's claim to have data that shows he
> delivers more features/code when he pairs (the data I have for various
> developers does not support this conclusion),

I don't think Ron said these were his conclusions; he said they were his 
observations - his data if you prefer.

Data matters, but so do the models or theories which make sense of the 
data. Lord Kelvin had "scientific" data on the age of the Earth, yet the 
conclusions he reached were wrong. Nor, it seems, was his interest in 
that particular problem motivated by purely "scientific" motives. The 
conclusions were wrong because there were things he didn't know about 
the system he was studying which made the data irrelevant.

> Absolute quality is a lofty altruistic goal, but it is way beyond the mark
> in terms of running a software development business.

I don't think anyone here is advocating "absolute" quality, whatever 
that means. I do think that a maintainable, well-factored system with no 
avoidable defects or egregious failures is an economical goal.

> From the data I have, it is very likely that the optimal development
> rate is one that includes part-time (15% - 35%) pair-programming and
> full-time unit-testing.

Optimal in what contexts ? Optimal on what dimension ?

When you say "part-time", you mean relative to what total ? "Body time" 
(hours in the office), total time spent at the keyboard, total time 
spent on implementation tasks ?

Laurent
http://bossavit.com/thoughts/

"Ilja Preu�" <preuss@disy.net> wrote in message news:<c5j0p0$6qj$1@stu1id2.ip.tesion.net>...

> >>> This school of thought:
> >>> "When you can measure what you are speaking about, and express it in
> >>> numbers, you know something about it; but when you cannot measure
> >>> it,
> >>> when you cannot express it in numbers, your knowledge of it is of a
> >>> meager and unsatisfactory kind; it may be the beginning of
> >>> knowledge,
> >>> but you have scarcely, in your thoughts, advanced it to the stage of
> >>> science."
> >>>
> >>> Sir William Thompson, Lord Kelvin (1824-1907)
> >>
> >> How much do you love your spouse, your kids if any, your parents?
> >
> > Love is immeasurable, so software development must be immeasurable
> > too?
> 
> If you can know something without objectively measuring it, perhaps there
> are other things for which it can work, too?

Kelvin had that covered: "your knowledge of it is of a meager and
unsatisfactory kind".

Most prefer to maintain the mystery of Love & Faith.
Why would someone prefer to make software development mysterious?

On Wed, 14 Apr 2004 06:10:02 -0000, Sebastian Stein <seb_stein@gmx.de>
wrote:

>On Tue, 13 Apr 2004 21:37:26 -0400, Ronald E Jeffries <ronjeffries@acm.org>
>wrote:
>>>>   Yes, XP teams generally have better schedules than they had before,
>>>> owing to the practice of breaking features down into smaller bits,
>>>> estimating all of them, and tracking velocity. This induces better
>>>> business decisions about which features to include and which ones to
>>>> defer.
>>>
>>>There might be a danger. By just estimating the small pieces and suming it
>>>up, you will get a too low estimation I think.
>>
>> Why would that be the case? And what would be the effect of tracking
>> actual velocity of implementation and using that to project end dates,
>> as we suggest?
>
>As I said, I'm not sure about it. I think in XP the problem is dealt with by
>the factor you multiplicate. Let's say you have 2 tasks each needing 4
>hours. Now you would think a pair could implement this in one day. But after
>finishing task 1, they maybe go out smoking or have to wait till they can
>switch the pair. This extra time is not in the estimates. Maybe they have to
>wait to get access to the integration computer (if they don't use CVS). Just
>looking at the tasks, I think you would miss such breaks. Nevertheless, this
>could be handled I think.

Sebastian, your recent remarks are making me think that you haven't
looked very deeply into XP at all. If that's the case, I'd
respectfully suggest that you'll profit from just a tiny bit more
study and a bit less speculation about it.

For example here, we don't multiply by a factor (though in early days
we did consider what we called "load factor") but instead we just
track how long it takes to do the story. So if it is a story of
dificulty 2, we expect that other stories of d=2 will take about the
same amount of time. That turns out to be sufficient, and quite
effective, for tracking and predicting.

I'm delighted to explain as much as I can here, of course.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 13 Apr 2004 22:55:16 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<co5p70tn9c39d546e01nmubbl5juitlqbe@4ax.com>...
>> On 13 Apr 2004 08:58:24 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>> 
>> >Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<9jdn70hlgej0smde9igb65uq2e3s7fcjee@4ax.com>...
>> >
>> >> I produce better code and more features when paired. 
>> >
>> >And you know that because you've measured the quality of code and
>> >number of features, you & your pair produce, with and without pairing?
>> 
>> I know it because I pay attention to how long it takes me to do
>> things, how much debugging I have to do, how often I'm down a rathole.
>
>Is "paying attention" the same as measuring and recording, or is it
>more...  intuitive?

More intuitive. Does that trouble you?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 13 Apr 2004 22:47:15 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<1s5p70tthuh5ol4hol3vgi8043ihmghi63@4ax.com>...
>
>> >This school of thought:
>> >"When you can measure what you are speaking about, and express it in
>> >numbers, you know something about it; but when you cannot measure it,
>> >when you cannot express it in numbers, your knowledge of it is of a
>> >meager and unsatisfactory kind; it may be the beginning of knowledge,
>> >but you have scarcely, in your thoughts, advanced it to the stage of
>> >science."
>> >
>> >Sir William Thompson, Lord Kelvin (1824-1907)
>> 
>> How much do you love your spouse, your kids if any, your parents?
>
>Love is immeasurable, so software development must be immeasurable too? 
>Confusion worse confounded.

No. It's just that there's more than one way to "measure". Do you have
enough in your pocket right now to take me to lunch? Don't look, don't
count. Just remember.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107o3dsgg61mffd@news.supernews.com>...

> Speaking broadly, there are only four general approaches
> in use today: code and fix, monolithic waterfall, plan driven
> and agile.

Speaking broadly, there's a continuum.

"Figure 1. The planning spectrum. Unplanned and undisciplined hacking
occupies
the extreme left, while micromanaged milestone planning, also known as
inchpebble planning, occupies the extreme right."

Get Ready for Agile Methods, with Care
http://www2.umassd.edu/SWPI/xp/papers/r1064.pdf

"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<107nvbm5lbn0j10@news.supernews.com>...

-snip-
> The plan-driven approach will produce more precise
> measurement, but the XP approach will produce more
> accurate measurements.

Precision vs accuracy really doesn't add anything to the story.

The underlying assumption is that each approach uses a different kind
of measurement to estimate project completion. We say that XP uses
measurements of delivered features, and then we say that "plan driven"
uses measurements of intermediate untested work products.

We're just assuming that the "plan driven" approach uses a longer
iteration period.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<fuiq709e2bvf2n9tk1dr57bh8l0jqqd8o5@4ax.com>...

> >Love is immeasurable, so software development must be immeasurable too? 
> >Confusion worse confounded.
> 
> No. It's just that there's more than one way to "measure". Do you have
> enough in your pocket right now to take me to lunch? Don't look, don't
> count. Just remember.

Did you have enough money in your pocket on Monday 14 April 2004 11:29AM PST? 
Monday 14 April 2003 11:29AM PST? Just remember.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<2tiq70p3t2cbpc5qag2ov24k5clnfhe9h0@4ax.com>...

> >> >> I produce better code and more features when paired. 
> >> >
> >> >And you know that because you've measured the quality of code and
> >> >number of features, you & your pair produce, with and without pairing?
> >> 
> >> I know it because I pay attention to how long it takes me to do
> >> things, how much debugging I have to do, how often I'm down a rathole.
> >
> >Is "paying attention" the same as measuring and recording, or is it
> >more...  intuitive?
> 
> More intuitive. Does that trouble you?

Not in the least.

Perhaps it would have been more straightforward to answer the original
question like this: "I know it based on what I can remember, not on
what I've measured."

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<4u5p70pi19m6qssitsuas6a79ihc23l0uf@4ax.com>...

> >Quite so, it's a question of role.
> >Ron has taken the role of XP promoter.
> 
> Not quite, my friend. I also help people who are interested in
> improving their software development results, and I'm fairly good at
> it.

We all play many roles in a variety of situations.
I was commenting on the role you take in these forums.

-snip-
> >Wondering whether there's more or less success, and why that might be,
> >is not the role of a promoter or a detractor.
> 
> Perhaps not. But I do wonder, and I pay attention. What I don't do is
> prove.

That's not very Test Driven ;-)

On 14 Apr 2004 11:48:07 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<4u5p70pi19m6qssitsuas6a79ihc23l0uf@4ax.com>...
>
>> >Quite so, it's a question of role.
>> >Ron has taken the role of XP promoter.
>> 
>> Not quite, my friend. I also help people who are interested in
>> improving their software development results, and I'm fairly good at
>> it.
>
>We all play many roles in a variety of situations.
>I was commenting on the role you take in these forums.
>
>-snip-
>> >Wondering whether there's more or less success, and why that might be,
>> >is not the role of a promoter or a detractor.
>> 
>> Perhaps not. But I do wonder, and I pay attention. What I don't do is
>> prove.
>
>That's not very Test Driven ;-)

On the contrary. I try things, I observe whether they work. If they
do, I do it again. If they don't, I don't.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Laurent,

> > If you give up three features, how much quality does it take to make up
for
> > those features?
>
> If you give up three features you didn't need, then overall quality will
> be higher and your costs will go down. Conversely, increased quality
> might mean shorter test-and-debug cycles, which in turn means more time
> available to implement features you do need.

Qualifying the three features as features you didn't need is an example of
the gaming that I mentioned when referring to GE in an earlier post.  So I
will restate the same question with a few more definitives.  If you give up
three features that you really need right now, but don't have enough time or
money to have pairs of programmers work on, how much quality do the
pair-programmers have to generate to make up for those features?

Here is my latest data point (without the data and names so I won't offend
anyone).  In January, a pair of developers on our team (not me), who enjoy
pair-programming and unit-testing, began pair-programming and unit-testing
work on feature changes to a large enterprise application to accommodate
some government regulation that take effect during mid-April.  Mid February
they stopped pair-programming and unit-testing because they weren't making
enough progress and would not be able to deliver the feature set on time.
After two more months of very intense, hard work individual-programming,
they are delivering the feature set.  It is obvious that they were right -- 
they could not have delivered the features if they continued to
pair-program.

The question is:

If the XP process lets two experienced developers get more done when
pair-programming as compared to working on tasks in parallel, why did they
feel they had to abandon the process to deliver the feature set?

The answer is:

The process doesn't let two experienced developers pair-program together for
one hour (spending two man-hours) and yield two man hours worth of work
product (code/features).  That is just break even anyway, although it would
be better if the code quality is better, which it probably would be better.

I believe that there are some out there, who will start gaming this latest
data-point to explain how these two developers are novices at the XP
practices, genetically deficient, etc.  Let me assure you that these are two
of the most talented and knowledgeable developers on staff.  Both are
team-lead-level developers.  They pair together quite well.  It would have
been nice for the company to spend the money to have both working on the
same code, but real-world business did not allow for this luxury.  This
real-world data-point, I hope, gives you a better understanding of what I
mean when I say that what is optimal for a couple of developers may not even
be close to what is optimal for the corporation.  I hope it also provides a
real-world example of trading code quality for features and vice versa.  In
the end, the two developers did what was right for the corporation, even
though many in the corporation were telling them to stick with
pair-programming, which is what would have been most beneficial to them
personally.

Regards,

Randy

On 13 Apr 2004 22:56:17 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<da5p705jqvgkde0mehu9pcmbqmra15vegn@4ax.com>...
>
>> >> I produce better code and more features when paired. 
>> >
>> >And you know that because you've measured the quality of code and
>> >number of features, you & your pair produce, with and without pairing?
>> 
>> Of course.  Don't you?
>
>Sometimes, sometimes not.
>So you have measurements for the work y'all did on Fitnesse?

Of course. We have velocity measurements, coverage measurements,
acceptance and unit test measurements.  I could probably infer coding
rates from the data if I wanted to.

I've already posted some of that data here.  Perhaps I'll write an
article about the project one day.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On 13 Apr 2004 18:43:08 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>The Waterfall model is so poorly named: Does water flow backwards up
>the waterfall? Nope. Yet Royce's 1970 Waterfall model included
>iteration within a phase (maybe he was thinking of whirlpools) and
>stepping back to a previous phase.

Royce's paper is the antithesis of what Waterfall has become.  As you
say, Royce made the point that the activities could not be conducted
in phases.  He separated the activities in concept, but not in time.
His diagram with arrows going in both directions simply means that the
activities will be concurrent.

Royce went on to say that one pass through all the activities isn't
enough.  He recommended going through them twice or more.  With just
one more little push, he'd have written a paper about iterative and
incremental development.

But that's not what we saw when we read that paper thirty four years
ago.  What we saw instead was phases with dates.  How we saw that I
can't say.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Wed, 14 Apr 2004 15:55:56 +0200, Laurent Bossavit
<laurent@dontspambossavit.com> wrote (more or less):

>Data matters, but so do the models or theories which make sense of the 
>data. Lord Kelvin had "scientific" data on the age of the Earth, yet the 
>conclusions he reached were wrong. Nor, it seems, was his interest in 
>that particular problem motivated by purely "scientific" motives. The 
>conclusions were wrong because there were things he didn't know about 
>the system he was studying which made the data irrelevant.

When you say ' "scientific" ', I think you mean ' scientific '.  His
data was neither unscientific nor irrelevant.  It was, as you do say,
incomplete for his task (i.e. none of his calculations or data took
account of the effect of continual radioactive heating of the Earth's
core).


Cheers, 
   Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki:  http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk)  http://html.dnsalias.net/gawnsoft/smalltalk

On Wed, 14 Apr 2004 22:12:58 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>Laurent,
>
>> > If you give up three features, how much quality does it take to make up
>for
>> > those features?
>>
>> If you give up three features you didn't need, then overall quality will
>> be higher and your costs will go down. Conversely, increased quality
>> might mean shorter test-and-debug cycles, which in turn means more time
>> available to implement features you do need.
>
>Qualifying the three features as features you didn't need is an example of
>the gaming that I mentioned when referring to GE in an earlier post.  So I
>will restate the same question with a few more definitives.  If you give up
>three features that you really need right now, but don't have enough time or
>money to have pairs of programmers work on, how much quality do the
>pair-programmers have to generate to make up for those features?

We'll see. If they introduce few enough defects, or if you spend
enough time in QA and fixing to remove them, then you'll wind up
ahead. If in their zeal to go faster, they introduce too many defects,
it will come back to bite you.

If they produce good enough code alone to keep their velocity high
over the duration of the project, then you'll wind up ahead. If in
programming alone, they leave the code in worse shape, or there is a
lot of code where at most one of them can work on it, the project will
slow down.

It's a judgment call.
>
>Here is my latest data point ...  It is obvious that they were right -- 
>they could not have delivered the features if they continued to
>pair-program.

I'll take that as given. Would be interesting to see the feature
delivery data, velocity info, etc ...

And I'm wondering whether other practices were slacked on as well. In
similar situations, I've seen teams also back off on unit tests and
acceptance tests and refactoring. They left some serious junk behind.
What happened in the case you are reporting, on those dimensions?
>
>The question is:
>
>If the XP process lets two experienced developers get more done when
>pair-programming as compared to working on tasks in parallel, why did they
>feel they had to abandon the process to deliver the feature set?

Seems clear that in this case, they were faster separately. Perhaps
the results were good enough, as discussed above, perhaps they were
not. I hope you'll come back and tell us what you learn about defects
and such after the thing ships.
>
>The answer is:
>
>The process doesn't let two experienced developers pair-program together for
>one hour (spending two man-hours) and yield two man hours worth of work
>product (code/features).  That is just break even anyway, although it would
>be better if the code quality is better, which it probably would be better.

Yes ...
>
>I believe that there are some out there, who will start gaming this latest
>data-point to explain how these two developers are novices at the XP
>practices, genetically deficient, etc.  Let me assure you that these are two
>of the most talented and knowledgeable developers on staff.  Both are
>team-lead-level developers.  They pair together quite well.  It would have
>been nice for the company to spend the money to have both working on the
>same code, but real-world business did not allow for this luxury.  This
>real-world data-point, I hope, gives you a better understanding of what I
>mean when I say that what is optimal for a couple of developers may not even
>be close to what is optimal for the corporation.  I hope it also provides a
>real-world example of trading code quality for features and vice versa.  In
>the end, the two developers did what was right for the corporation, even
>though many in the corporation were telling them to stick with
>pair-programming, which is what would have been most beneficial to them
>personally.

Well, not shipping on time is not beneficial to me personally, so I'm
not clear what you mean by most beneficial.

I'd like to see the velocity data, and I hope you'll keep an eye on
quality issues and see what you can figure out about defect density in
the paired and unpaired code.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Wed, 14 Apr 2004 10:31:30 -0400, Ronald E Jeffries <ronjeffries@acm.org>
wrote:
> Sebastian, your recent remarks are making me think that you haven't
> looked very deeply into XP at all. If that's the case, I'd
> respectfully suggest that you'll profit from just a tiny bit more
> study and a bit less speculation about it.

Yes, I have not looked much into the field of estimation, because it is not
important for me at the moment. I'm more interested in the general approach
and the core principles behind. Estimation is just one detail...

> For example here, we don't multiply by a factor (though in early days
> we did consider what we called "load factor") but instead we just
> track how long it takes to do the story. So if it is a story of
> dificulty 2, we expect that other stories of d=2 will take about the
> same amount of time. That turns out to be sufficient, and quite
> effective, for tracking and predicting.

This sounds good. In other words you classify the tasks and you moved to
discreet estimates.

Sebastian
-- 
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial

Isaac Gouy wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:<c5j0p0$6qj$1@stu1id2.ip.tesion.net>...
>
>>>>> This school of thought:
>>>>> "When you can measure what you are speaking about, and express it
>>>>> in
>>>>> numbers, you know something about it; but when you cannot measure
>>>>> it,
>>>>> when you cannot express it in numbers, your knowledge of it is of
>>>>> a
>>>>> meager and unsatisfactory kind; it may be the beginning of
>>>>> knowledge,
>>>>> but you have scarcely, in your thoughts, advanced it to the stage
>>>>> of
>>>>> science."
>>>>>
>>>>> Sir William Thompson, Lord Kelvin (1824-1907)
>>>>
>>>> How much do you love your spouse, your kids if any, your parents?
>>>
>>> Love is immeasurable, so software development must be immeasurable
>>> too?
>>
>> If you can know something without objectively measuring it, perhaps
>> there
>> are other things for which it can work, too?
>
> Kelvin had that covered: "your knowledge of it is of a meager and
> unsatisfactory kind".

How did he measure this?

> Most prefer to maintain the mystery of Love & Faith.
> Why would someone prefer to make software development mysterious?

"Not measured" doesn't imply "mysterious" to me. I do know that Pair
Programming works better in most cases for me, and I have opinions on why.
And for none of the people I know who tried it for some time does it seem to
be mysterious.

Cheers, Ilja

Isaac Gouy wrote:
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
> news:<fuiq709e2bvf2n9tk1dr57bh8l0jqqd8o5@4ax.com>...
>
>>> Love is immeasurable, so software development must be immeasurable
>>> too?
>>> Confusion worse confounded.
>>
>> No. It's just that there's more than one way to "measure". Do you
>> have
>> enough in your pocket right now to take me to lunch? Don't look,
>> don't
>> count. Just remember.
>
> Did you have enough money in your pocket on Monday 14 April 2004
> 11:29AM PST?
> Monday 14 April 2003 11:29AM PST? Just remember.

Did Pair Programming work for me at that time? I don't remember, and I don't
care.

What I do know is that most often I do have enough money in my pocket to
take someone to lunch, and that I could tell instantly for any given
situation wether I do, without ever having measured it.

Cheers, Ilja

PS: Isaac, Ron, if you are ever in Karlsruhe, Germany, remember me to take
you to lunch... ;)

Randy:

> > If you give up three features you didn't need, then overall quality will
> > be higher and your costs will go down.
> 
> Qualifying the three features as features you didn't need is an example of
> the gaming that I mentioned when referring to GE in an earlier post.

Thanks for clarifying "gaming". It seems to me that the "needed/not 
needed" distinction is fair game, however, based on... industry data, 
which suggests that many of the features built into a system are never 
actually used.

So let's use "gaming", but call this type "fair gaming", to indicate 
that I am bringing into a play a distinction not made previously in the 
conversation, but which at least one of us considers relevant.

Are you familiar with the ideas in Robert Austin's book, "Measuring and 
Managing Performance in Organizations ?" Your discussion of "gaming" 
suggests you might be.

> If you give up three features that you really need right now, but don't
> have enough time or money to have pairs of programmers work on, how much
> quality do the pair-programmers have to generate to make up for those features?

No amount of extra quality in features X, Y Z will make up for not 
having features A, B, C if you actually needed them.

However, I want to point out that if features X, Y, Z lack essential 
quality attributes - such as, they actually work - then you're missing 
not three, but six features.

> In January, a pair of developers on our team (not me), who enjoy
> pair-programming and unit-testing, began pair-programming and unit-testing
> work on feature changes to a large enterprise application to accommodate
> some government regulation that take effect during mid-April.

Just out of curiosity, I'd like to know when it became known that the 
regulation change would take effect in April. That does not necessarily 
have any bearing on our conversation, but then again it might.

> It is obvious that they were right -- they could not have delivered the
> features if they continued to pair-program.

By "obvious", do you mean that their velocity in mid-February (three 
iterations into the effort) was such that you could predict some 
features would be missing by mid-April (four iterations later) ?

If so, can you divulge the measure of the total scope (in "story 
points" or some other unit), and the observed velocity during the first 
three iterations ? I'd like to know how much of a feature shortfall 
we're talking about.

> After two more months of very intense, hard work individual-programming,
> they are delivering the feature set.

That's good. So you have measured the gain in terms of number of 
features delivered per unit time, which is one important dimension of 
the development effort.

By "very intense, hard work", do you mean that the two worked more hours 
than usual ? Was this taken into account in the "number of features per 
unit time" calculation ?

How are you measuring the quality shortfall ? How are you measuring the 
cost of that quality shortfall ?

My concern and the reason for this line of questioning is that, as 
Austin argues in the reference above, there is a kind of "gaming" that 
commonly goes on in organizations. Measurements are made of the things 
which are easy to measure, leading to strong pressure for improved 
performance along these dimensions. At the same time, no measurements 
are made of the things harder to measure, and no pressure applied there. 
However, for any given dimension of performance, "easy to mesure" does 
not correlate well with "criticality to business results". Measurement 
efforts therefore tend to have adverse effects, because people respond 
to the differential pressure by slacking off on the aspects not 
measured, even if they are critical to business results.

Laurent
http://bossavit.com/thoughts/

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<of5s7011v4inaamv8o2ls65grlnh7ub8km@4ax.com>...

> >> >> I produce better code and more features when paired. 
> >> >
> >> >And you know that because you've measured the quality of code and
> >> >number of features, you & your pair produce, with and without pairing?
> >> 
> >> Of course.  Don't you?
> >
> >Sometimes, sometimes not.
> >So you have measurements for the work y'all did on Fitnesse?
> 
> Of course. We have velocity measurements, coverage measurements,
> acceptance and unit test measurements.  I could probably infer coding
> rates from the data if I wanted to.
> 
> I've already posted some of that data here.  Perhaps I'll write an
> article about the project one day.

Excellent, we have some 'after' measurements, what about the 'before' measurements?

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<fpqr709gflc1far17kavds588t7mo1povv@4ax.com>...

> >> Perhaps not. But I do wonder, and I pay attention. What I don't do is
> >> prove.
> >
> >That's not very Test Driven ;-)
> 
> On the contrary. I try things, I observe whether they work. If they
> do, I do it again. If they don't, I don't.

Wouldn't that be: define the test, check it fails, try things, check the test? ;-)

(Sample size of one is kind-of small?)

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<j16s705k51bm229nr6vvvl5c80l6tfvi25@4ax.com>...

> But that's not what we saw when we read that paper thirty four years
> ago.  What we saw instead was phases with dates.  How we saw that I
> can't say.

The usual organizational change issue: the new thing comes along so
'of course' we're now doing the new thing - except we continue to do
the old (stagewise) thing.

(What was that quip about OO? In 20 years everyone will be doing OO
and no one will know what it is?)

On 15 Apr 2004 07:18:40 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<fpqr709gflc1far17kavds588t7mo1povv@4ax.com>...
>
>> >> Perhaps not. But I do wonder, and I pay attention. What I don't do is
>> >> prove.
>> >
>> >That's not very Test Driven ;-)
>> 
>> On the contrary. I try things, I observe whether they work. If they
>> do, I do it again. If they don't, I don't.
>
>Wouldn't that be: define the test, check it fails, try things, check the test? ;-)

TDD is a programming technique, providing feedback (and a nice test
suite as a side effect). Feedback is a life technique.
>
>(Sample size of one is kind-of small?)

It's the first point of feedback. Prudent to pay attention to it. Not
prudent to overreact.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<ip4p70l44lf7tkrutq6mn9klo3f0gajed6@4ax.com>...

> We might.  However, what I've noticed is that folks who adopt an agile
> method don't really care much whether it is XP or FDD, or SCRUM.

Could that be because most of the benefit comes from just using an
iterative approach - any iterative approach?

"Iterative and Incremental Development: A Brief History"
http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

(For me the interesting distinction is between iterative approaches to
development and iterative approaches to delivery.)

"Ilja Preu�" <preuss@disy.net> wrote in message news:<c5lmtl$lqo$1@stu1id2.ip.tesion.net>...

> > Most prefer to maintain the mystery of Love & Faith.
> > Why would someone prefer to make software development mysterious?
> 
> "Not measured" doesn't imply "mysterious" to me. I do know that Pair
> Programming works better in most cases for me, and I have opinions on why.
> And for none of the people I know who tried it for some time does it seem to
> be mysterious.

Trust and verify.

Sometimes I do user-interaction design. Folk will argue passionately
that the menu layout they have is so much faster/easier-to-use/...
than any other design could be.
And then we measure. Even though these folk are the world experts in
using their particular menu layout, there seems to be a 50/50 chance
that they themselves are significantly faster using some other design.
Self assessment of performance is notoriously inaccurate.

It isn't worth debating things which can be measured.

Randy A. Ynchausti wrote:

> Laurent,
> 
> 
>>>If you give up three features, how much quality does it take to make up
> 
> for
> 
>>>those features?
>>
>>If you give up three features you didn't need, then overall quality will
>>be higher and your costs will go down. Conversely, increased quality
>>might mean shorter test-and-debug cycles, which in turn means more time
>>available to implement features you do need.
> 
> Qualifying the three features as features you didn't need is an example of
> the gaming that I mentioned when referring to GE in an earlier post.  So I
> will restate the same question with a few more definitives.  If you give up
> three features that you really need right now, but don't have enough time or
> money to have pairs of programmers work on, how much quality do the
> pair-programmers have to generate to make up for those features?

Seems this is oddly being treated as either/or. Perhaps this is just the 
circumstance of the example stated further below.

When *planning*, it is not uncommon to consider whether the available 
team can meet a particular deadline with a particular number of features 
(stories), using a sustainable pace. The answer is not always yes. 
Sometimes changes to the "givens" of the project need to be made. 
Business managers are aware of this. They typically prefer to find out 
sooner rather than later. Often, however, they are not told until it is 
essentially too late to remedy the situation.

However, if the GoldOwner is informed well ahead of time of looming 
problems and responds "get them all done by the deadline no matter what, 
but without adding team members to the project", then you might not have 
an environment that is suitable to XP. This does not seem to be directly 
related to the efficiency or otherwise of a practice that includes 
pair-programming versus a recommended practice that does not include 
pair-programming.

> Here is my latest data point (without the data and names so I won't offend
> anyone).  In January, a pair of developers on our team (not me), who enjoy
> pair-programming and unit-testing, began pair-programming and unit-testing
> work on feature changes to a large enterprise application to accommodate
> some government regulation that take effect during mid-April.  Mid February
> they stopped pair-programming and unit-testing because they weren't making
> enough progress and would not be able to deliver the feature set on time.
> After two more months of very intense, hard work individual-programming,
> they are delivering the feature set.  It is obvious that they were right -- 
> they could not have delivered the features if they continued to
> pair-program.

CowboyCoding is faster than XP in short spurts. CopyAndPasteProgramming 
is faster than TestDrivenDevelopment in short spurts. I don't think that 
anybody here will dispute that.

And, nobody here is going to question peoples motives for trying to meet 
a tight deadline. The question is what are the repercussions. What 
happens if you keep doing this? If this was a one time occurance, and 
everyone can clean up and move on afterwards, fine. If the code is not 
valuable after the deadline, fine. But, if this becomes commonplace, and 
there will be new deadlines immediately following the previous ones, 
yes, quality, and eventually development speed will suffer. The rabbit 
will lose the race.

> The question is:
> 
> If the XP process lets two experienced developers get more done when
> pair-programming as compared to working on tasks in parallel, why did they
> feel they had to abandon the process to deliver the feature set?

I believe that the discussion was about programmers following certain 
practices alone versus practicing XP in pairs.

What practice did these programmers follow when they abandoned 
pair-programmig and unit-testing? It sounds like they resorted to 
CowboyCoding (coding like mad).

What is your point? That programmers coding like mad can produce lower 
quality code faster in short spurts than an XP team can produce high 
quality, low-defect code in a sustainable fashion? OK, fine. Been there, 
done that. So what?

How long can they keep this up? When do they burn out and move on? How 
much time is wasted dealing with the increased level of defects? How 
much time is lost while the programmers slow down to catch their breath 
after the deadline? How much time is lost with cleaning up messes made 
*in the interests of saving time* Etc, ...

Are you recommending "code like mad" as a better practice for developers 
overall, in the general case?

> The answer is:
> 
> The process doesn't let two experienced developers pair-program together for
> one hour (spending two man-hours) and yield two man hours worth of work
> product (code/features).  That is just break even anyway, although it would
> be better if the code quality is better, which it probably would be better.
> 
> I believe that there are some out there, who will start gaming this latest
> data-point to explain how these two developers are novices at the XP
> practices, genetically deficient, etc.  Let me assure you that these are two

No, not at all. These are real-world humans placed in a real-world 
difficult situation, probably doing the best they can think of at the 
time. The decisions reached, however, may not be the same decisions that 
other teams would have reached. And, it is not clear who was making the 
decisions, the programmers or the business manager.

Also, pair-programming is not an all or nothing issue. Especially if 
there are only two developers on the team. Pair-programming is most 
beneficial when the developers can switch pairs to remain fresh. That is 
not possible with only two developers. I am personally aware of ways to 
deal with this if you are sincerely interested.

> of the most talented and knowledgeable developers on staff.  Both are
> team-lead-level developers.  They pair together quite well.  It would have
> been nice for the company to spend the money to have both working on the
> same code, but real-world business did not allow for this luxury.  This

If the business people are going to require that developers "code like 
mad" to make unrealistic deadlines, what process do you think will help 
them out? How long can they keep that process up?

What happens when the business manager starts to assume that the team 
can keep up this pace indefinitely (Why can't you "code like mad" all 
the time? Why would you not operate at top speed at all times?)? The 
reality is that *before* that point the developers need to tell the 
business manager that the deadlines are not realistic. If the business 
manager does not listen, what process will solve this problem?

> real-world data-point, I hope, gives you a better understanding of what I
> mean when I say that what is optimal for a couple of developers may not even
> be close to what is optimal for the corporation.  I hope it also provides a

What is optimal for most corporations and most business managers is to 
know what is a realistic workload for a given team of developers 
*before* committing to deadlines, or at the earliest possible opportunity.

If the developers chose to throw out a process rather than discuss a 
problem with the business manager, they were not valuing communication 
as highly as some other teams experienced with XP I'm aware of.

If, however, the problem was presented, and the business manager just 
responded "tough, just get it done", then the organization may not place 
a high level of importance on some of the values that XP promotes.

> real-world example of trading code quality for features and vice versa.  In
> the end, the two developers did what was right for the corporation, even
> though many in the corporation were telling them to stick with
> pair-programming, which is what would have been most beneficial to them
> personally.

XP practices are beneficial to organizations that value low-defects, a 
sustainable pace, and early feedback. If those benefits are not 
important to the organization, then perhaps XP is not a good fit.

> Regards,
> 
> Randy

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Isaac:

> It isn't worth debating things which can be measured.

Agreed, and thanks for the example. The one you gave is of a situation 
where it's (apparently) possible to obtain the ideal of measurement: 
varying one parameter, "all other things being equal", and measuring the 
results on one relevant dimension.

The rest of the time, we are faced with problems where all other things 
are never equal, and the results have more than one relevant dimension.

As per another part of this thread, some dimensions will be easy to 
measure (e.g. "faster" task performance in interaction design) and 
others less easy (e.g. retention of UI procedures or accuracy in 
performing the tasks). And the easy ones are often allowed to stand as 
the most important to optimize.

Laurent
http://bossavit.com/thoughts/

On Wed, 14 Apr 2004 22:12:58 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>Laurent,
>
>> > If you give up three features, how much quality does it take to make up
>for
>> > those features?
>>
>> If you give up three features you didn't need, then overall quality will
>> be higher and your costs will go down. Conversely, increased quality
>> might mean shorter test-and-debug cycles, which in turn means more time
>> available to implement features you do need.
>
>Qualifying the three features as features you didn't need is an example of
>the gaming that I mentioned when referring to GE in an earlier post.  So I
>will restate the same question with a few more definitives.  If you give up
>three features that you really need right now, but don't have enough time or
>money to have pairs of programmers work on, how much quality do the
>pair-programmers have to generate to make up for those features?

Measure the time spent in debuggers.  What if you could eliminate this
time and reallocate it to feature development?  If, by pairing, and by
test driven development, you could reduce debugging time by a factor
of ten, how many more features could you get done?

My own anecdotal data tells me that I get more done when I pair, and
when I use TDD.  Pairing alone without tests is useful to me, but lots
of time gets spent in debugging so it doesn't seem to pay off as well.
For example, my pair partner and I had a problem yesterday that cost
us three hours.  (He had a spurious java.exe installed in a directory
that happened to be in the path, and it was getting executed in a
bizarre context).  Having both of us working on that problem at the
same time was probably inefficient.  On the other hand, when we were
programming together we were going very fast, and there were virtually
no bugs.

>Here is my latest data point (without the data and names so I won't offend
>anyone).  In January, a pair of developers on our team (not me), who enjoy
>pair-programming and unit-testing, began pair-programming and unit-testing
>work on feature changes to a large enterprise application to accommodate
>some government regulation that take effect during mid-April.  Mid February
>they stopped pair-programming and unit-testing because they weren't making
>enough progress and would not be able to deliver the feature set on time.
>After two more months of very intense, hard work individual-programming,
>they are delivering the feature set.  It is obvious that they were right -- 
>they could not have delivered the features if they continued to
>pair-program.

Was it the same two guys working together for six weeks?  Were they
writing their unit tests *first*?  

I trust their decision.  They're probably right that they wouldn't
have gotten done.  I have found that when you pair two people long
term, things don't work out very well.  At Object Mentor, we had two
programmers who started out pairing well, and then stopped pairing
altogether after a few weeks.  On the other hand, when we brought some
summer interns in, the pairing went up dramatically, and so did
morale, and productivity.

The really good XP teams that I see nowadays pair at about 70% to 80%.
Pairings are short lived (a day or less), and programmers will often
pick certain tasks to work on alone.

>The question is:
>
>If the XP process lets two experienced developers get more done when
>pair-programming as compared to working on tasks in parallel, why did they
>feel they had to abandon the process to deliver the feature set?
>
>The answer is:
>
>The process doesn't let two experienced developers pair-program together for
>one hour (spending two man-hours) and yield two man hours worth of work
>product (code/features).  That is just break even anyway, although it would
>be better if the code quality is better, which it probably would be better.

I think that's a simplistic answer.  There's too much evidence to the
contrary.  I have certainly seen cases where two programmers don't
work efficiently together.  I have also seen (and experienced) cases
where pairing has led to remarkable efficiencies.

>I believe that there are some out there, who will start gaming this latest
>data-point to explain how these two developers are novices at the XP
>practices, genetically deficient, etc.  Let me assure you that these are two
>of the most talented and knowledgeable developers on staff.  Both are
>team-lead-level developers.  They pair together quite well.  It would have
>been nice for the company to spend the money to have both working on the
>same code, but real-world business did not allow for this luxury.  This
>real-world data-point, I hope, gives you a better understanding of what I
>mean when I say that what is optimal for a couple of developers may not even
>be close to what is optimal for the corporation.  I hope it also provides a
>real-world example of trading code quality for features and vice versa.  In
>the end, the two developers did what was right for the corporation, even
>though many in the corporation were telling them to stick with
>pair-programming, which is what would have been most beneficial to them
>personally.

I believe they did what was right.  I also believe that there might
have been other strategies to apply that could have more nearly
satisfied their goals, and the company's goals.  


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On 15 Apr 2004 08:02:41 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<j16s705k51bm229nr6vvvl5c80l6tfvi25@4ax.com>...
>
>> But that's not what we saw when we read that paper thirty four years
>> ago.  What we saw instead was phases with dates.  How we saw that I
>> can't say.
>
>The usual organizational change issue: the new thing comes along so
>'of course' we're now doing the new thing - except we continue to do
>the old (stagewise) thing.
>
>(What was that quip about OO? In 20 years everyone will be doing OO
>and no one will know what it is?)

Prescient!



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1ae8d37a1acce888989754@news.noos.fr>...

> > It isn't worth debating things which can be measured.
> 
> Agreed, and thanks for the example. The one you gave is of a situation 
> where it's (apparently) possible to obtain the ideal of measurement: 
> varying one parameter, "all other things being equal", and measuring the 
> results on one relevant dimension.
> 
> The rest of the time, we are faced with problems where all other things 
> are never equal, and the results have more than one relevant dimension.

In that example we had one varying parameter, and results on multiple
dimensions - however the point of the anecdote was that, in general,
self-assessments are a waste of breath.

Back in the '20s the needs of agriculture drove the initial
development of multifactor experimental design and supporting
statistics - engineering has a varied and rich heritage.


> As per another part of this thread, some dimensions will be easy to 
> measure (e.g. "faster" task performance in interaction design) and 
> others less easy (e.g. retention of UI procedures or accuracy in 
> performing the tasks). And the easy ones are often allowed to stand as 
> the most important to optimize.

Is designing a measure that different to designing a test?

Isaac:

> > As per another part of this thread, some dimensions will be easy to 
> > measure [...] the easy ones are often allowed to stand as 
> > the most important to optimize.
> 
> Is designing a measure that different to designing a test?

I don't understand the question, or how it relates to the part of my 
post you were quoting. Can you please clarify ?

Laurent
http://bossavit.com/thoughts/

> --- Robert C. Martin <unclebob@objectmentor.com> wrote...
>> But that's not what we saw when we read that paper thirty four
years
>> ago.  What we saw instead was phases with dates.  How we saw that I
>> can't say.

--- igouy@yahoo.com (Isaac Gouy) wrote...
> The usual organizational change issue: the new thing comes along so
> 'of course' we're now doing the new thing - except we continue to do
> the old (stagewise) thing.
> 
> (What was that quip about OO? In 20 years everyone will be doing OO
> and no one will know what it is?)

20 years???
My answer would be more like "5 years ago."   ;->

When they told me that their word processor was Object Oriented, and
therefore I would enjoy all the benefits of its OO-ness, I was just
dumbfounded.  (No, they were not talking about a COM interface to
their internal DOM.)

Ron,

> >Qualifying the three features as features you didn't need is an example
of
> >the gaming that I mentioned when referring to GE in an earlier post...
>
> We'll see. If they introduce few enough defects, or if you spend
> enough time in QA and fixing to remove them, then you'll wind up
> ahead. If in their zeal to go faster, they introduce too many defects,
> it will come back to bite you.

By gaming, I mean redefining things until they fit into the problem domain
nicely.  That is what GE did.  Without data, it is always possible to game
the situation.  Claim that there is more of a problem or less of a problem.
The zeal to go faster was not zeal at all.  It was a recognition that the
government regulations had to be met and the developers had to deliver and
that could not be done if they continued to pair-program.  There was nothing
about zeal that drove them to quit pair-programming.  It was all about sound
professional judgement to achieve the efficiency and productivity to be able
to meet the deadline.

> If in programming alone, they leave the code in worse shape, or
> there is a lot of code where at most one of them can work on it,
> the project will slow down.
>
> It's a judgment call.

This is where we think differently.  To me it is not a judgement call, it is
a business decision.  Business data (metrics that yield cost vs. benefits),
sound experience/judgement and some prediction of future trends drive the
decisions we make -- whether to pair-program, etc.  We also hope for some
good luck too.

> >Here is my latest data point ...  It is obvious that they were right -- 
> >they could not have delivered the features if they continued to
> >pair-program.
> >
> >If the XP process lets two experienced developers get more done when
> >pair-programming as compared to working on tasks in parallel, why did
they
> >feel they had to abandon the process to deliver the feature set?
>
> Seems clear that in this case, they were faster separately. Perhaps
> the results were good enough, as discussed above, perhaps they were
> not. I hope you'll come back and tell us what you learn about defects
> and such after the thing ships.

In case you are wonder about complexity, let me note that it will take about
two full days of downtime (a.k.a. lots of money) to finish all of the code
cutover and database migration work that has to be done to support the new
features (including the OO client, OO server/database and relational
server/database).  The code has passed QA and will be cutover to production
this weekend, guaranteed.  I am confident that there will not be any major
issues.  But I promise to let you know if there are!

> I'd like to see the velocity data, and I hope you'll keep an eye on
> quality issues and see what you can figure out about defect density in
> the paired and unpaired code.

Sorry, I don't quite see your interest in the velocity data -- since it will
show that pair-programming produces somewhere near half as many features as
individual programming produces; and suggest that a team pair-programming
100% is not as productive as a team working individually (and/or pairing
infrequently -- 15% - 35% of the time).

I have already done some studies regarding this.  My data shows that
experienced developers working alone and practicing unit-testing produce
essentially the same amount of code with the same number of defects as
experienced developers working together in pairs.  There is a very obvious
hint to this type of comparison in the paper, "Integrating Unit Testing Into
A Software Development Team's Process" that was presented at the "2nd
International Conference on eXtreme Programming and Flexible Processes in
Software Engineering (XP2001)."

Regards,

Randy

Randy A. Ynchausti wrote:

> Qualifying the three features as features you didn't need is an
> example of the gaming that I mentioned when referring to GE in an
> earlier post.  So I will restate the same question with a few more
> definitives.  If you give up three features that you really need
> right now, but don't have enough time or money to have pairs of
> programmers work on, how much quality do the pair-programmers have to
> generate to make up for those features?

They'd have to generate enough quality that the reduced workload made it
possible to implement those three features.

If you get short of time, you don't need to type faster. What you need to
do, in my experience, is to find ways to have to type less - by finding
things you can defer until later, by using a simpler design, by not going
down ratholes... with other words, by being creative.

In my experience, PP is very effective in fostering creativity.

> If the XP process lets two experienced developers get more done when
> pair-programming as compared to working on tasks in parallel, why did
> they feel they had to abandon the process to deliver the feature set?
>
> The answer is:
>
> The process doesn't let two experienced developers pair-program
> together for one hour (spending two man-hours) and yield two man
> hours worth of work product (code/features).  That is just break even
> anyway, although it would be better if the code quality is better,
> which it probably would be better.

I am not sure that this is the answer.

I started learning PP on a hobby project, PPing with a friend. At first, it
was real fun, and we certainly were making fast progress. After some weeks,
though, we started being at odds more and more often, and we enjoyed working
together less and less, until the project came to halt. (I think that
inappropriate furniture had some role to play.)

When I started working at my current employee three years ago, we I used to
pair program with a coworker to get started into the project. We both
enjoyed the experience very much, but after some time, again we dropped it.
(Our project managers weren't very supportive regarding PP at that time. In
fact they tended to divide the project into "one subproject per developer".)

Same project, some months ago; we are now beginning to gel into a team of
four developers. Project manager, though quite sceptical, agrees on a small
experiment - my friend (who has joined the project shortly after me) and me
are allowed to pair program on a critical task for roughly 50% for a week.
It runs quite well - we don't slow down (to the surprise of the manager) and
quality is increased (as we all suspected). The manager warily agrees to
continue doing pair programming for around 50% of the time. Nevertheless,
the amount of PP we do again decreases...

But my friend is frustrated about having to work alone, so she persuades the
other two coworkers to try PPing with her, too. Slowly, there is more and
more PPing going on.

Today, we are totally free to do as much PP as we see fit. I guess we do
around 70% PP, with changing partners every couple of days. I also think
that we will do even more in the future, and I will try to push us towards
experimenting with changing partners more often.

> I believe that there are some out there, who will start gaming this
> latest data-point to explain how these two developers are novices at
> the XP practices, genetically deficient, etc.  Let me assure you that
> these are two of the most talented and knowledgeable developers on
> staff.  Both are team-lead-level developers.  They pair together
> quite well.

In my opinion, pairing is not only a matter of working well together. It is
also about being able to inspire each other. In my experience, if you don't
change partners regularly, you loose (part of) this ability, so that pairing
becomes stale.

> In the
> end, the two developers did what was right for the corporation, even
> though many in the corporation were telling them to stick with
> pair-programming, which is what would have been most beneficial to
> them personally.

We find that most often pair programming is beneficial to both the
corporation and to us personally. When feel that it isn't, we don't do it.
Everything else would be nonprofessional.

Cheers, Ilja

Randy A. Ynchausti wrote:

> I have already done some studies regarding this.  My data shows that
> experienced developers working alone and practicing unit-testing
> produce essentially the same amount of code with the same number of
> defects as experienced developers working together in pairs.

The same amount of code, or the same amount of business value?

Curious, Ilja

Isaac Gouy wrote:

> Sometimes I do user-interaction design. Folk will argue passionately
> that the menu layout they have is so much faster/easier-to-use/...
> than any other design could be.

So they didn't try and get comfortable with a different design yet?

> And then we measure. Even though these folk are the world experts in
> using their particular menu layout, there seems to be a 50/50 chance
> that they themselves are significantly faster using some other design.
> Self assessment of performance is notoriously inaccurate.

Self assessment without experimentation, certainly.

Take care, Ilja

> Ronald E Jeffries wrote:
>> The irony of Extreme Programming is that while detractors continue 
>> to  explain why it cannot work, software developers all over the
>> world are having success with it.
>> 
>> http://www.xprogramming.com/xpmag/jatIronyOfXP.htm

Phlip wrote:
> If they all posted here, they'd drown out the dissent (the same way
> the occassional troll gets drowned out on the XP mailing list).
> 
> They don't post here, because of the detractors.

In this thread, as it stands so far, the only dissent I see is from 
somebody who has tried a technique, measured the results, and found it 
lacking. Whereas those drowning out that signal, have not measured 
results, but are presenting anecdotal or theoretical evidence to the 
contrary. Now there's irony.

The fact that there is rarely any dissenting opinion on the XP mailing 
list is the main reason that I rarely follow it. Without dissent, all 
that remains is self congratulation.

What has maintained my interest in XP the most is the failure of the C3 
project. Without the failure of a project that is definitively XP, it's 
easy to fall into the trap of defining XP with circular reasoning. The 
reason no true XP project can succeed is the same reason that no true XP 
project can fail: it's a failure to communicate. It's the same reason 
that no true Scotsman puts sugar in his porridge...

http://c2.com/cgi/wiki?NoTrueScotsman

Failure must be an option for success to have meaning.

"Ilja Preu�" <preuss@disy.net> wrote in message news:<c5odm1$65h$1@stu1id2.ip.tesion.net>...

> > Sometimes I do user-interaction design. Folk will argue passionately
> > that the menu layout they have is so much faster/easier-to-use/...
> > than any other design could be.
> 
> So they didn't try and get comfortable with a different design yet?

They'd tried several designs, in sequence, as they thought of them,
for a week or so, and stayed with the design they felt was best (by
which they mean't quickest to use/fewest errors...).

They never measured which was best according to their criteria - and
actually discarded a design that performed far better than the one
they prefered. And they became emotionally invested in the prefered
design.


> > And then we measure. Even though these folk are the world experts in
> > using their particular menu layout, there seems to be a 50/50 chance
> > that they themselves are significantly faster using some other design.
> > Self assessment of performance is notoriously inaccurate.
> 
> Self assessment without experimentation, certainly.

Experimentation - would that be measure and test?

jgrigg@mo.net (Jeff Grigg) wrote in message news:<c794c0fd.0404151829.5cb7c20e@posting.google.com>...

> > (What was that quip about OO? In 20 years everyone will be doing OO
> > and no one will know what it is?)
> 
> 20 years???
> My answer would be more like "5 years ago."   ;->

IIRC this was in the early '80s, sorry I haven't been able to trace
the original statement.

Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<407fbd54$1@news.totallyobjects.com>...
> > Ronald E Jeffries wrote:
> >> The irony of Extreme Programming is that while detractors continue 
> >> to  explain why it cannot work, software developers all over the
> >> world are having success with it.
> >> 
> >> http://www.xprogramming.com/xpmag/jatIronyOfXP.htm
> 
> Phlip wrote:
> > If they all posted here, they'd drown out the dissent (the same way
> > the occassional troll gets drowned out on the XP mailing list).
> > 
> > They don't post here, because of the detractors.
> 
> In this thread, as it stands so far, the only dissent I see is from 
> somebody who has tried a technique, measured the results, and found it 
> lacking. Whereas those drowning out that signal, have not measured 
> results, but are presenting anecdotal or theoretical evidence to the 
> contrary. Now there's irony.
-snip-

> Failure must be an option for success to have meaning.

Clarity! That's why it was fun working with you on the Bowling Game ;-)

On Fri, 16 Apr 2004 11:57:14 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>What has maintained my interest in XP the most is the failure of the C3 
>project. Without the failure of a project that is definitively XP, it's 
>easy to fall into the trap of defining XP with circular reasoning. The 
>reason no true XP project can succeed is the same reason that no true XP 
>project can fail: it's a failure to communicate. It's the same reason 
>that no true Scotsman puts sugar in his porridge...
>
>http://c2.com/cgi/wiki?NoTrueScotsman
>
>Failure must be an option for success to have meaning.

An interesting position and an interesting analogy.

Certainly, after four years of shipping running tested software on the
schedule predicted (if not the schedule desired), the C3 project was
terminated.

It's certainly interesting to know why it was cancelled. I have stated
my views on that any number of times. I have the apparently minor
advantage of having actually been there, but there are others, who
never were and who have never talked to anyone who was, who apparently
know better what "really happened". I wish I knew how to know things
like that, it would surely come in handy.

But its cancellation is interesting, nonetheless. I'm not sure whether
I'd call it failure, but it wasn't as happy an outcome as we had
contemplated.

On the other hand, the project shipped running, working, tested
software, on the schedule it predicted, from the first month right
through to the last. I think that's interesting, because I've seen few
projects do that, and according to the Standish Report, my experience
is not atypical.

So lots of good things happened, things that I think are what XP
speaks to -- putting people with needs together with people who
develop, and getting solid, predictable results.

And some bad things happened, three or four levels above the project.
Some of those might have been averted had there been better
communication from the project team, up through four levels of IT
management, and up through four or maybe five levels of Finance
management, to the two people who made the decision. Or, it might have
happened sooner, which if it was to happen, would have been a good
thing in a business sense.

Did XP fail there? Frankly I don't think so. Did I, or Chet, or Denny,
or Paul, or someone above those people? Quite possibly yes. The upward
management people weren't on our team, but somehow they must not have
been getting what they wanted.

Anyway, whatever keeps you interested is good ...

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries wrote:
> An interesting position and an interesting analogy.
> 
> Certainly, after four years of shipping running tested software on
> the schedule predicted (if not the schedule desired), the C3 project
> was terminated.
> 
> It's certainly interesting to know why it was cancelled. I have
> stated my views on that any number of times. I have the apparently
> minor advantage of having actually been there, but there are others,
> who never were and who have never talked to anyone who was, who
> apparently know better what "really happened". I wish I knew how to
> know things like that, it would surely come in handy.

I think the reason we see so much speculation from people who weren't
there is because there is so little information from those who were. It
may be too late to do a public post mortem now. But it's a shame that it 
wasn't done at the time; given the high profile nature of the project.

> But its cancellation is interesting, nonetheless. I'm not sure
> whether I'd call it failure, but it wasn't as happy an outcome as we
> had contemplated.

Failure, or success for that matter, is a continuum. All projects
have a share of both. But, as near as I can tell from the wiki pages, 
the overall goal of the C3 project was to replace many legacy payroll 
systems with a single solution:

  "I am involved in a Gemstone project at Chrysler to replace their many
   payroll applications with a single application. The project has been
   going on for a couple of years. I was brought in to help with
   performance tuning, but ended up as a sort of head coach of an effort
   to start fresh." -- Kent Beck

And, as we know, the project was canceled before this goal was reached. 
There is also a report that Daimler Chrysler are trying again:

  "Daimler Chrysler still wants to replace all of their payrolls systems
   with a single solution and are gearing up to spend about 4 times C3's
   total cost to do it. This will be Daimler Chrysler's fifth attempt to
   do this." -- Chet Hendrickson

So C3 did not reach it's goal. And it's not because Daimler Chrysler 
didn't want a single payroll system. C3 has added to the legacy systems 
that a fifth solution will have to replace. To me, that colours C3 a 
failure. And I don't think that is an uncommon view:

  "If I remember correctly Frank [Gerhardt] said words to the effect
   that, at Daimler Chrysler these days the terms: 'C3', 'eXtreme
   programming' and especially 'planning game", and to some extent
   'Smalltalk', 'Gemstone' and 'object-oriented' are now unutterable by
   anyone wishing management there to take them seriously. He got a
   rather nervous sounding chuckle from the audience with the line
   Chrysler has done XP once and only once...'"

  "The impression amongst the folk I spoke to was that in the view of
   DC's management C3 was a disastrous project, and never the like shall
   be seen again there." -- Keith Braithwaite

That was written a while back. I would be interested to know if the 
situation has changed there recently.

But I also understand that there was a lot that worked well.

> So lots of good things happened, things that I think are what XP 
> speaks to -- putting people with needs together with people who 
> develop, and getting solid, predictable results.

Keith also said of C3, "this echoes some of my own, and others', 
experiences when applying (some of) the practices: when one gets down to 
brass tacks, successful delivery of working software sometimes turns out 
not to be the thing most desired by the gold owner after all."

> Did XP fail there? Frankly I don't think so. Did I, or Chet, or
> Denny, or Paul, or someone above those people? Quite possibly yes.

Indeed. There was most certainly a failure somewhere. I suspect it was 
Chet's fault :-)

 > The upward management people weren't on our team, but somehow they
 > must not have been getting what they wanted.

This reminds me of the ending of "The Night Before Startup":
http://www.annoyances.org/exec/show/article09-209

    The system was finished, the tests were concluded,
    the client�s last changes were even included.
    Then the user explained in apocalypt font,
    "It�s just what I asked for, but not what I want."

Ronald E Jeffries wrote in The Irony Of Extreme Programming:
>>>>I know it because I pay attention to how long it takes me to do
>>>>things, how much debugging I have to do, how often I'm down a rathole.

Isaac Gouy wrote:
>>>Is "paying attention" the same as measuring and recording, or is it
>>>more...  intuitive?

Ronald E Jeffries:
>>More intuitive. Does that trouble you?

Isaac Gouy wrote:
> Not in the least.

There is a problem with using memory of experience over recording. It is 
  known as the "peak-end" rule. In short, the rule is that we summarise 
our experiences by how they were at their peak (best or worst) and how 
they ended. This produces a subjective memory that is often at odds with 
an objective measurement.

In "The Paradox of Choice," Barry Schwartz gives a graphic example which 
  I will summarise below. Those of a squeamish disposition should stop 
reading now...

Two groups of men having colonoscopy exams were asked to keep a minute 
by minute account of their experience and to rate the experience when it 
was over. The scope is a tube with a remotely controlled camera on the 
end. It is inserted through the rectum to inspect the gastrointestinal 
system. The first group had a normal colonoscopy exam. The second had 
the same exam, but the scope was left in place for another twenty 
seconds before it was removed.

Both groups reported similar peak levels of discomfort. But after the 
exam was over, the second group (which had a greater total discomfort) 
rated the experience as less unpleasant than the first. This was because 
the experience of the inserted scope is less unpleasant than the 
experience of the exam itself. Their end experience was better, 
therefore their memory of the experience was better.

And it made a real difference to the recall rate. Over a five year 
period, those in the second group were more likely to respond to calls 
for follow-up exams because they remembered the experience as less 
unpleasant.

On Fri, 16 Apr 2004 23:27:37 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>
>  "If I remember correctly Frank [Gerhardt] said words to the effect
>   that, at Daimler Chrysler these days the terms: 'C3', 'eXtreme
>   programming' and especially 'planning game", and to some extent
>   'Smalltalk', 'Gemstone' and 'object-oriented' are now unutterable by
>   anyone wishing management there to take them seriously. He got a
>   rather nervous sounding chuckle from the audience with the line
>   Chrysler has done XP once and only once...'"
>
>  "The impression amongst the folk I spoke to was that in the view of
>   DC's management C3 was a disastrous project, and never the like shall
>   be seen again there." -- Keith Braithwaite
>
>That was written a while back. I would be interested to know if the 
>situation has changed there recently.

Yes. I am in possession of an internal DC document recommending that
XP be used for projects where the requirements are uncertain.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Fri, 16 Apr 2004 23:27:37 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>Keith also said of C3, "this echoes some of my own, and others', 
>experiences when applying (some of) the practices: when one gets down to 
>brass tacks, successful delivery of working software sometimes turns out 
>not to be the thing most desired by the gold owner after all."

Yes. And XP, like most of its "competitors", is a software development
process. It may not be appropriate to "blame" such a process for
failures of this other kind.
>
>> Did XP fail there? Frankly I don't think so. Did I, or Chet, or
>> Denny, or Paul, or someone above those people? Quite possibly yes.
>
>Indeed. There was most certainly a failure somewhere. I suspect it was 
>Chet's fault :-)

Unquestionably ...
>
> > The upward management people weren't on our team, but somehow they
> > must not have been getting what they wanted.
>
>This reminds me of the ending of "The Night Before Startup":
>http://www.annoyances.org/exec/show/article09-209
>
>    The system was finished, the tests were concluded,
>    the client�s last changes were even included.
>    Then the user explained in apocalypt font,
>    "It�s just what I asked for, but not what I want."

Yes, sort of, though in fact I think it /was/ largely what the
customer wanted, but not what some upper-level folks wanted. And
again, all XP claims to be is a way to deliver what the customer asks
for, in a style that gives him maximum chance to decide it isn't what
he wants, early on.

Asking it to solve hunger or executive-level politics is asking it a
question it isn't designed to solve ... nor is there any other process
that solves those things to compare with.

Or so it seems to me ...

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

> <paul.sinnett@btinternet.com> wrote:
>>   "It�s just what I asked for, but not what I want."

Ronald E Jeffries wrote:
> Yes, sort of, though in fact I think it /was/ largely what the
> customer wanted, but not what some upper-level folks wanted. And
> again, all XP claims to be is a way to deliver what the customer asks
> for, in a style that gives him maximum chance to decide it isn't what
> he wants, early on.

Okay, so we know not to use XP where management requirements and 
customer requirements aren't aligned.

But what was the difference between what the management wanted and what 
the customer wanted in the case of C3?

The requirements seem to be spelled out in Kent's summary of the project:

  "I am involved in a Gemstone project at Chrysler to replace their many
   payroll applications with a single application."

Earlier you wrote:
> Certainly, after four years of shipping running tested software on the
> schedule predicted (if not the schedule desired), the C3 project was
> terminated.

This suggests that management was unhappy with the progress rather than 
wanting something different?

On Sat, 17 Apr 2004 12:12:13 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>> <paul.sinnett@btinternet.com> wrote:
>>>   "It�s just what I asked for, but not what I want."
>
>Ronald E Jeffries wrote:
>> Yes, sort of, though in fact I think it /was/ largely what the
>> customer wanted, but not what some upper-level folks wanted. And
>> again, all XP claims to be is a way to deliver what the customer asks
>> for, in a style that gives him maximum chance to decide it isn't what
>> he wants, early on.
>
>Okay, so we know not to use XP where management requirements and 
>customer requirements aren't aligned.

I don't know much about C3, but I observe that when management
requirements and customer requirements are not aligned, the project is
in deep trouble -- irrespective of process.




-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Robert C. Martin wrote:
> <paul.sinnett@btinternet.com> wrote:
>> Okay, so we know not to use XP where management requirements and 
>> customer requirements aren't aligned.
> 
> I don't know much about C3, but I observe that when management 
> requirements and customer requirements are not aligned, the project
> is in deep trouble -- irrespective of process.

This risk is so common among projects that it is regarded by DeMarco and
Lister as one of the five core risks that almost every project faces.
They call it "specification breakdown" which usually results in an
ambiguous contract that all the parties feel able to sign. The problem is:

  "While it is possible to specify a product ambiguously, it is not
   possible to build a product ambiguously. Eventually, the deferred
   problems need to be faced..." -- Waltzing with Bears, Tom DeMarco and
   Timothy Lister.

The probability of this risk hitting a project runs at around 10-15%, 
depending on who you talk to, and usually results in cancellation.

Theory-W Management addresses this particular problem directly. It was
designed by Barry Boehm for use with his Spiral Lifecycle. Perhaps it
could be adapted to work with XP since they are fairly similar anyway?

Or maybe it would be better to use Spiral if conflicting interests seem 
likely, and save XP for those project where this risk cannot occur - 
such as when the customers and management are the same people, or the 
developers and management are the same people?

But, if resign ourselves to accepting this risk in every case, we have 
to be willing to have 10-15% of our projects canceled. So it is with risk.

"Isaac Gouy" <igouy@yahoo.com> schrieb im Newsbeitrag
news:ce7ef1c8.0404160708.7e36ea72@posting.google.com...
> "Ilja Preu�" <preuss@disy.net> wrote in message
news:<c5odm1$65h$1@stu1id2.ip.tesion.net>...
>
> > > Sometimes I do user-interaction design. Folk will argue passionately
> > > that the menu layout they have is so much faster/easier-to-use/...
> > > than any other design could be.
> >
> > So they didn't try and get comfortable with a different design yet?
>
> They'd tried several designs, in sequence, as they thought of them,
> for a week or so, and stayed with the design they felt was best (by
> which they mean't quickest to use/fewest errors...).

Do you have an idea on why the felt that way?

> They never measured which was best according to their criteria - and
> actually discarded a design that performed far better than the one
> they prefered. And they became emotionally invested in the prefered
> design.

Did you persuade them to use the better design? How? How do they feel about
it today, after using it for a longer time? How would they probably feel if
they had the option to go back to the design they initially preferred?

> > > And then we measure. Even though these folk are the world experts in
> > > using their particular menu layout, there seems to be a 50/50 chance
> > > that they themselves are significantly faster using some other design.
> > > Self assessment of performance is notoriously inaccurate.
> >
> > Self assessment without experimentation, certainly.
>
> Experimentation - would that be measure and test?

It would be trying something with an open mind, long enough to learn it
adequately and to overcome preconceptions.

Of course there also always has to be some measurement - if only "how much
do you like it".

There certainly is also a place for more objective measurement. I am not
sure that it is always as objective as we think, and far from convinced that
it is the only way to know something well enough to make reasonable
decisions.

Cheers, Ilja

> Okay, so we know not to use XP where management requirements and
> customer requirements aren't aligned.

I'd rather say we know that we need to take care that management
expectations and customer expectations get aligned.

Do you see anything in XP which would make this harder than using a
different process?

Curious, Ilja

On Sat, 17 Apr 2004 08:39:22 -0500, Robert C. Martin
<unclebob@objectmentor.com> wrote (more or less):

>On Sat, 17 Apr 2004 12:12:13 +0100, Paul Sinnett
><paul.sinnett@btinternet.com> wrote:
>
>>> <paul.sinnett@btinternet.com> wrote:
>>>>   "It’s just what I asked for, but not what I want."
>>
>>Ronald E Jeffries wrote:
>>> Yes, sort of, though in fact I think it /was/ largely what the
>>> customer wanted, but not what some upper-level folks wanted. And
>>> again, all XP claims to be is a way to deliver what the customer asks
>>> for, in a style that gives him maximum chance to decide it isn't what
>>> he wants, early on.
>>
>>Okay, so we know not to use XP where management requirements and 
>>customer requirements aren't aligned.
>
>I don't know much about C3, but I observe that when management
>requirements and customer requirements are not aligned, the project is
>in deep trouble -- irrespective of process.

Very true.

It in fact, one of the key reasons behind the method I designed for
Benefits Realisation  

(which I've started to document in the public domain at 
http://c2.com/cgi/wiki?BenefitsRealization
but failed to expound on due to lack of discernable expressed interest
there!  :-)  )


Cheers, 
   Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki:  http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk)  http://html.dnsalias.net/gawnsoft/smalltalk

On Sat, 17 Apr 2004 12:12:13 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>> <paul.sinnett@btinternet.com> wrote:
>>>   "It�s just what I asked for, but not what I want."
>
>Ronald E Jeffries wrote:
>> Yes, sort of, though in fact I think it /was/ largely what the
>> customer wanted, but not what some upper-level folks wanted. And
>> again, all XP claims to be is a way to deliver what the customer asks
>> for, in a style that gives him maximum chance to decide it isn't what
>> he wants, early on.
>
>Okay, so we know not to use XP where management requirements and 
>customer requirements aren't aligned.
>
>But what was the difference between what the management wanted and what 
>the customer wanted in the case of C3?
>
>The requirements seem to be spelled out in Kent's summary of the project:
>
>  "I am involved in a Gemstone project at Chrysler to replace their many
>   payroll applications with a single application."
>
>Earlier you wrote:
>> Certainly, after four years of shipping running tested software on the
>> schedule predicted (if not the schedule desired), the C3 project was
>> terminated.
>
>This suggests that management was unhappy with the progress rather than 
>wanting something different?

It's actually quite complex. As I understand it, IT management started
C3 as an experiment to learn what the role of OO was at Chrysler.
Although projects done by IT there are paid for by the customers, they
offered the Finance department a "free" payroll program if they'd
support the experiment with customer input and such. There was also a
Y2K aspect in there.

As time went on, everything changed. Literally every manager on the
Finance side, save one, transferred out. Literally every manager on
the IT side transferred out. The DaimlerChrysler "merger" took place,
and the Chrysler CIO, a supporter of the project, became DC CIO and
responsible for saving seven BILLION dollars in "synergy savings" in
the two companies' IT budgets. This in an organization where the net
budget was essentially zero because of the funding of projects by
customers.

The time came when IT had to have the project paid for, to get the
savings. Finance, who had never really cared that much, declined. By
that time none of the original supporters of the project were in the
same jobs, or in the chain of command. So they unfunded the project,
at the CIO's office. 

Were they unhappy? Well, they would have preferred that it be over and
done with, complete. The progress and end dates projected by the team
were holding up. They were not what was desired, but worse, the
IT-side manager of the project literally refused, in my hearing, to
tell his boss what the real schedule was. He let the supposed schedule
stand, until the day came when it was obvious that it would not be
met. That didn't help any.

I've remarked publicly that I wonder what might have happened
differently had I personally called on the CIO and told her the truth.
I would surely have been removed from the project, but it would have
brought matters to a head sooner. Whether it would have been better or
worse for the project or the team, I cannot know. In any case, I
didn't do that.

So we had a project which was delivering what it said it could, when
it said it could, all running, all tested, all confirmed against the
existing payroll. The information the project had was blocked by
management from going where it needed to go. It was certainly not the
best possible result, but it was also outside the scope of most any
software development method. Still bad, I'm not saying that it wasn't.
But was it a problem with XP, or with people outside the XP purview? I
believe the latter. Still bad, though.

What do you think?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Sat, 17 Apr 2004 15:41:56 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>This risk is so common among projects that it is regarded by DeMarco and
>Lister as one of the five core risks that almost every project faces.
>They call it "specification breakdown" which usually results in an
>ambiguous contract that all the parties feel able to sign. The problem is:
>
>  "While it is possible to specify a product ambiguously, it is not
>   possible to build a product ambiguously. Eventually, the deferred
>   problems need to be faced..." -- Waltzing with Bears, Tom DeMarco and
>   Timothy Lister.
>
>The probability of this risk hitting a project runs at around 10-15%, 
>depending on who you talk to, and usually results in cancellation.
>
>Theory-W Management addresses this particular problem directly. It was
>designed by Barry Boehm for use with his Spiral Lifecycle. Perhaps it
>could be adapted to work with XP since they are fairly similar anyway?
>
>Or maybe it would be better to use Spiral if conflicting interests seem 
>likely, and save XP for those project where this risk cannot occur - 
>such as when the customers and management are the same people, or the 
>developers and management are the same people?

What do you see as the important difference between Spiral and XP in
this regard? XP delivers running tested software in priority order,
visible to all concerned. What does Spiral do, in your view, that is
better?

Thanks,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

> --- Ronald E Jeffries wrote:
>> Certainly, after four years of shipping running tested software
>> on the schedule predicted (if not the schedule desired), the C3
>> project was terminated.

C3 put software into production, which was used to print real
paychecks for real people for some years.  By most conventional
measures, this would be called a success.  Certainly, this is a much
higher level of success than what I've seen of quite a few other
projects.  ;->

--- Paul Sinnett <paul.sinnett@btinternet.com> wrote...
> [...], as near as I can tell from the wiki pages, the overall goal
> of the C3 project was to replace many legacy payroll systems with
> a single solution:
>   "I am involved in a Gemstone project at Chrysler to replace their many
>    payroll applications with a single application. The project has been
>    going on for a couple of years. I was brought in to help with
>    performance tuning, but ended up as a sort of head coach of an effort
>    to start fresh." -- Kent Beck

RE:
  "replace their many payroll applications with a single application"
  "The project has been going on for a couple of years."

To me, this has "doomed project" written all over it.


> That was written a while back. I would be interested to know if the 
> situation has changed there recently.

A few years later, I saw papers published as to what a great success
XP projects were having at DC.  They were quite proud of their
accomplishments.

"Ilja Preuss" <ilja.preuss@web.de> wrote in message news:<4081469e@news.totallyobjects.com>...

> > They'd tried several designs, in sequence, as they thought of them,
> > for a week or so, and stayed with the design they felt was best (by
> > which they mean't quickest to use/fewest errors...).
> 
> Do you have an idea on why the felt that way?

The gist of what they expressed is that they had used the various
designs and from their "experience" the design they fixed-upon was
quickest to use / fewest errors...

> > They never measured which was best according to their criteria - and
> > actually discarded a design that performed far better than the one
> > they prefered. And they became emotionally invested in the prefered
> > design.
> 
> Did you persuade them to use the better design? 

Not before finding out which was the better design ;-)

(One of the nice things about measuring stuff is that you find out
just how wrong you can be.)

> How? 

Discount usability testing (look at Nielsens papers).

There were some folk who spent a week playing the test like gamers -
trying to get there scores up for 'the prefered design'. After that
they acknowledged the obvious.

> How do they feel about it today, after using it for a longer time? 
> How would they probably feel if they had the option to go back to the design
> they initially preferred?

No idea. 

-snip-
> There certainly is also a place for more objective measurement. I am not
> sure that it is always as objective as we think, and far from convinced that
> it is the only way to know something well enough to make reasonable
> decisions.

Measurement seems intrinsic to the operation of agile methods -
project velocity? The apparent lack of interest in measuring where the
payoff comes from in agile methods is surprising to me.

(Mostly we make decisions on the basis of name recognition - see
"Simple Heuristics That Make Us Smart".)

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<4mc280hase3bd9uj3cf33il9ub47lrruj2@4ax.com>...

> I don't know much about C3, but I observe that when management
> requirements and customer requirements are not aligned, the project is
> in deep trouble -- irrespective of process.


Not only "management requirements" and "customer requirements" but
- Business goals
- Business strategies
- Business processes
- System interactions
- Technical constraints

http://www.objectmonkey.com/index.php?A=getcolumnpiece&Ar=p=38^c=5^i=14^

On Sat, 17 Apr 2004 15:41:56 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>Robert C. Martin wrote:
>> <paul.sinnett@btinternet.com> wrote:
>>> Okay, so we know not to use XP where management requirements and 
>>> customer requirements aren't aligned.
>> 
>> I don't know much about C3, but I observe that when management 
>> requirements and customer requirements are not aligned, the project
>> is in deep trouble -- irrespective of process.
>
>This risk is so common among projects that it is regarded by DeMarco and
>Lister as one of the five core risks that almost every project faces.
>They call it "specification breakdown" which usually results in an
>ambiguous contract that all the parties feel able to sign. The problem is:
>
>  "While it is possible to specify a product ambiguously, it is not
>   possible to build a product ambiguously. Eventually, the deferred
>   problems need to be faced..." -- Waltzing with Bears, Tom DeMarco and
>   Timothy Lister.
>
>The probability of this risk hitting a project runs at around 10-15%, 
>depending on who you talk to, and usually results in cancellation.

This doesn't seem to be what happened to C3.  If I can be so
presumptuous as to speak for the folks who were really there, it seems
that the requirements were never ambiguous.  Perhaps the ambiguity
related more to whether the company as a whole actually wanted a
payroll replacement or not.  Clearly *someone* did; and that someone
paid for initial development.  However after the initial successes the
project was canceled because the payroll department refused to pick up
the rest of the development costs.  Apparently the *real* user didn't
want the system badly enough to pay even for a fraction of it.

If I have recounted this correctly (and anyone who was there, please
feel free to correct me), then my naive analysis is that the project
should never have been started.  The users of the project never wanted
it badly enough to pay for it. 


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Ron,

> > > The upward management people weren't on our team, but somehow they
> > > must not have been getting what they wanted.

> Yes, sort of, though in fact I think it /was/ largely what the
> customer wanted, but not what some upper-level folks wanted.

This is truely the irony of extreme programming.

Regards,

Randy

"Isaac Gouy" wrote
> "Ilja Preuss" <ilja.preuss@web.de> wrote in message
news:<4081469e@news.totallyobjects.com>...
>
> > > They'd tried several designs, in sequence, as they thought of them,
> > > for a week or so, and stayed with the design they felt was best (by
> > > which they mean't quickest to use/fewest errors...).
> >
> > Do you have an idea on why the felt that way?
>
> The gist of what they expressed is that they had used the various
> designs and from their "experience" the design they fixed-upon was
> quickest to use / fewest errors...

OK, that is what they expressed. Do you have an idea on why they expressed
it?

> > > They never measured which was best according to their criteria - and
> > > actually discarded a design that performed far better than the one
> > > they prefered. And they became emotionally invested in the prefered
> > > design.
> >
> > Did you persuade them to use the better design?
>
> Not before finding out which was the better design ;-)
>
> (One of the nice things about measuring stuff is that you find out
> just how wrong you can be.)

That's certainly an interesting observation. I would also find it very
interesting *why* they were wrong.

> > How?
>
> Discount usability testing (look at Nielsens papers).
>
> There were some folk who spent a week playing the test like gamers -
> trying to get there scores up for 'the prefered design'. After that
> they acknowledged the obvious.
>
> > How do they feel about it today, after using it for a longer time?
> > How would they probably feel if they had the option to go back to the
design
> > they initially preferred?
>
> No idea.

So how do you know that your measurement was accurate?

> -snip-
> > There certainly is also a place for more objective measurement. I am not
> > sure that it is always as objective as we think, and far from convinced
that
> > it is the only way to know something well enough to make reasonable
> > decisions.
>
> Measurement seems intrinsic to the operation of agile methods -
> project velocity? The apparent lack of interest in measuring where the
> payoff comes from in agile methods is surprising to me.

I think that would be interest in measurement, there just are higher
priorities than measuring this particular case for many of us.


> (Mostly we make decisions on the basis of name recognition - see
> "Simple Heuristics That Make Us Smart".)

Already on my wish list after I have seen it mentioned in the discussion
with Laurent. (Guess on how I decided about this... ;)

Cheers, Ilja

On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>Ron,
>
>> > > The upward management people weren't on our team, but somehow they
>> > > must not have been getting what they wanted.
>
>> Yes, sort of, though in fact I think it /was/ largely what the
>> customer wanted, but not what some upper-level folks wanted.
>
>This is truely the irony of extreme programming.

This is truly the irony of programming.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

"Ilja Preuss" <ilja.preuss@web.de> wrote in message news:<40823e2b@news.totallyobjects.com>...

> > The gist of what they expressed is that they had used the various
> > designs and from their "experience" the design they fixed-upon was
> > quickest to use / fewest errors...
> 
> OK, that is what they expressed. Do you have an idea on why they expressed
> it?
Please rephrase. (The answer that comes to mind is they expressed it
because the believed it to be true - which makes me think I don't
understand what you're asking.)

> That's certainly an interesting observation. I would also find it very
> interesting *why* they were wrong.
The testing wasn't intended to answer that question, and doesn't.
 
> So how do you know that your measurement was accurate?
Although the sample size was modest, a dozen; the results were
repeatable and unambiguous - for every subject the 'preferred' design
took twice as long and had >twice the error rate.

"Isaac Gouy" <igouy@yahoo.com> schrieb im Newsbeitrag
news:ce7ef1c8.0404180918.1342fd1e@posting.google.com...
> "Ilja Preuss" <ilja.preuss@web.de> wrote in message
news:<40823e2b@news.totallyobjects.com>...
>
> > > The gist of what they expressed is that they had used the various
> > > designs and from their "experience" the design they fixed-upon was
> > > quickest to use / fewest errors...
> >
> > OK, that is what they expressed. Do you have an idea on why they
expressed
> > it?
> Please rephrase. (The answer that comes to mind is they expressed it
> because the believed it to be true - which makes me think I don't
> understand what you're asking.)

Well, it's not the only answer that comes to my mind. I could imagine a
situation where people wouldn't express the real reason for preferring a
specific layout - either because theyself don't know the reason, or because
they feel that it wouldn't be accepted.

But let's accept that they believed it to be true - do you have an idea on
why they did so? (I gather that this may become annoying to you. I am sorry
if that is the case, and wouldn't object if you wanted to finish the thread.
But I am really curious, and don't know how else to proceed... :o )

> > That's certainly an interesting observation. I would also find it very
> > interesting *why* they were wrong.
> The testing wasn't intended to answer that question, and doesn't.

Do you think there would be value in knowing that?

> > So how do you know that your measurement was accurate?
> Although the sample size was modest, a dozen; the results were
> repeatable and unambiguous - for every subject the 'preferred' design
> took twice as long and had >twice the error rate.

Mhh, sorry, my bad - I didn't want to imply that there was something wrong
with the measurement.

What I wanted to get at was: how do you know that going with the more
effective design according to your measurement was in fact the most
effective decision regarding the whole project? Could there have been
something wrong with it that wasn't measured by your experiment?

Regards, Ilja

"Randy A. Ynchausti" <randy_ynchausti@msn.com> schrieb im Newsbeitrag
news:4082031b$1@news.totallyobjects.com...
> Ron,
>
> > > > The upward management people weren't on our team, but somehow they
> > > > must not have been getting what they wanted.
>
> > Yes, sort of, though in fact I think it /was/ largely what the
> > customer wanted, but not what some upper-level folks wanted.
>
> This is truely the irony of extreme programming.

In which way is it more connected to XP than, say, the usage of Smalltalk?

Puzzled, Ilja

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:uf1580597kkpkq9i4gdvjhjvkqouqc8fuq@4ax.com...
| On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
| <randy_ynchausti@msn.com> wrote:
|
| >Ron,
| >
| >> > > The upward management people weren't on our team, but somehow they
| >> > > must not have been getting what they wanted.
| >
| >> Yes, sort of, though in fact I think it /was/ largely what the
| >> customer wanted, but not what some upper-level folks wanted.
| >
| >This is truely the irony of extreme programming.
|
| This is truly the irony of programming.

But how do you get anyone in the upper-levels to sign off on anything other
than adopting a methodology?

>>>> [...] I think it /was/ largely what the customer wanted,
>>>> but not what some upper-level folks wanted.

>>> This is truely the irony of extreme programming.

>> This is truly the irony of programming.

"Randy at Home" <rsbecker_whatever@hotmail.com_nospam_atall> wrote...
> But how do you get anyone in the upper-levels to sign off on
> anything other than adopting a methodology?

Maybe, in the best of organizations, top-level leadership may buy into
the concept of enabling people to make choices as to how to improve
their work -- and actually support them in doing this.  That is,
instead of just talking about empowerment, they might actually do it.


Now as far as replacing a variety of payroll systems with one "do it
all" system, someone needs to ask themselves why they really want to
do this.  In their case, it appears that given their multiple failures
in achieving it, they must not want it strong enough to overcome the
difficulties.  (Maybe some organizations would be better served by a
psychological evaluation, rather than a better software development
methodology.  ;-)

Isaac Gouy wrote:
> Measurement seems intrinsic to the operation of agile methods -
> project velocity? The apparent lack of interest in measuring where the
> payoff comes from in agile methods is surprising to me.

Measurement is very important and is probably done on almost every Agile 
Project.

You've probably heard of the Agile Manifesto. On the Agile Alliance 
website, you can also find a list of Agile Principles. One in particular 
jumps out as highly relevant in a discussion of measurement:

"Working software is the primary measure of progress"

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Paul Sinnett wrote:

> Ronald E Jeffries wrote in The Irony Of Extreme Programming:

So, Ron actually wrote part of "The Irony of Extreme Programming". We 
need to talk with him about that... -just kidding, I got a chuckle out 
of this little usenet-ism.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Randy at Home wrote:
> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:uf1580597kkpkq9i4gdvjhjvkqouqc8fuq@4ax.com...
>> On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
>> <randy_ynchausti@msn.com> wrote:
>>
>>> Ron,
>>>
>>>>>> The upward management people weren't on our team, but somehow
>>>>>> they must not have been getting what they wanted.
>>>
>>>> Yes, sort of, though in fact I think it /was/ largely what the
>>>> customer wanted, but not what some upper-level folks wanted.
>>>
>>> This is truely the irony of extreme programming.
>>
>> This is truly the irony of programming.
>
> But how do you get anyone in the upper-levels to sign off on anything
> other than adopting a methodology?

What does "signing off" have to do with it?

Confused, Ilja

> difficulties.  (Maybe some organizations would be better served by a
> psychological evaluation, rather than a better software development
> methodology.  ;-)

"Many", not "some".

Laurent

"Ilja Preuss" <ilja.preuss@web.de> wrote in message news:<4082ded6@news.totallyobjects.com>...

> Well, it's not the only answer that comes to my mind. I could imagine a
> situation where people wouldn't express the real reason for preferring a
> specific layout - either because theyself don't know the reason, or because
> they feel that it wouldn't be accepted.

A couple of folk on the team "prefered" one of the other designs they
had already tried - and still opined that what I have been referring
to as the 'prefered design' performed better. They were all initially
resistant to the idea that the 'prefered design' didn't perform.

> But let's accept that they believed it to be true - do you have an idea on
> why they did so? 

I can invent a bundle of rationalizations ;-)
When using each design they were focused on the task they were
performing, not on how many errors they made nor how quickly they
performed the task. Being subject and observer at the same time
doesn't work well.
They didn't measure and record, so they had to try and remember back
to what they felt about previous designs, and what they felt about
previous designs involved all kinds of other things (was their kid
having problems at school that week?).

>(I gather that this may become annoying to you
Frustrating not annoying - when I complete a project I usually have to
leave behind all the working documents and measurements (unlike Paul
O'Neill).

> > > I would also find it very interesting *why* they were wrong.
> Do you think there would be value in knowing that?
Not in this case, they were a bit too clueless.

Look for James Reason's work: "Broadening the cognitive engineering
horizons: More engineering, less cognition and no philosophy of
science, please"
 
> What I wanted to get at was: how do you know that going with the more
> effective design according to your measurement was in fact the most
> effective decision regarding the whole project? Could there have been
> something wrong with it that wasn't measured by your experiment?

Can we untangle that a little - we're making a judgement about which
design performed better according to some criteria, and we're making a
judgement about which design to use on the project.
We can find that design X performs better, and still decide to use
design Y for all manner of reasons (valid, invalid, arbitrary,
whatever).

IMO the interesting question would be "Was there something wrong...
which we could have discovered using some other approach, with similar
costs?"

("Could" seems to ask "Is it possible?" All kinds of things are
possible.)

"Ilja Preuss" <ilja.preuss@web.de> wrote in message news:<4082ded6@news.totallyobjects.com>...
 
> But I am really curious, and don't know how else to proceed... 

"Sources of Power: How People Make Decisions"
http://www.decisionmaking.com/approach/sourcesofpower.html

"Why We Buy: The Science of Shopping" Paco Underhill

"INFOSENSE Turning Data and Information into Knowledge"
Keith Devlin

Ilja Preuss wrote:
> I'd rather say we know that we need to take care that management
> expectations and customer expectations get aligned.
> 
> Do you see anything in XP which would make this harder than using a
> different process?

I don't see anything in XP which deals with this at all.

That is, in Planning Extreme Programming we have the customer's bill of 
rights, and the programmer's bill of rights. But there's no manager's 
bill of rights. Maybe there needs to be one...

What do you see as management's role within an XP project?

Ronald E Jeffries wrote:
> What do you think?

I think it all sounds very familiar.

One thing still puzzles me though. If DC still want to replace their 
legacy payroll with a single solution and are willing to pay through the 
nose for it, why not restart C3? Starting afresh only adds to the number 
of systems they will have to replace. Is it that they don't think C3 can 
be extended?

Jeff Grigg wrote:
> A few years later, I saw papers published as to what a great success
> XP projects were having at DC.  They were quite proud of their
> accomplishments.

Do you have any references for those projects?

Paul Sinnett wrote:
> Ilja Preuss wrote:
> 
>> I'd rather say we know that we need to take care that management
>> expectations and customer expectations get aligned.
>>
>> Do you see anything in XP which would make this harder than using a
>> different process?
> 
> I don't see anything in XP which deals with this at all.

Are you aware of any *software development process* that specifically 
addresses the situation "where management requirements and customer 
requirements aren't aligned"?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Jason,

> >> I'd rather say we know that we need to take care that management
> >> expectations and customer expectations get aligned.
> >>
> >> Do you see anything in XP which would make this harder than using a
> >> different process?
> >
> > I don't see anything in XP which deals with this at all.
>
> Are you aware of any *software development process* that specifically
> addresses the situation "where management requirements and customer
> requirements aren't aligned"?

Yes, any development process that includes upfront requirements that are
signed off by the customer and management has this alignment.  Whether the
software team can deliver then becomes the issue.  Note that there may be
valid reasons why the software development team can not deliver, but this
does not negate the fact that the customer and management are aligned.

Regards,

Randy

Randy A. Ynchausti wrote:

>> Are you aware of any *software development process* that specifically
>> addresses the situation "where management requirements and customer
>> requirements aren't aligned"?
>
> Yes, any development process that includes upfront requirements that
> are signed off by the customer and management has this alignment.

Sign off on a requirement documents doesn't guarantee alignement at all.
Keep in mind that on the C3 project, the people canceling the project
weren't even there when there could have been a sign off, as far as I
understand.

What I would want to have is both customers and management being aware of
what's currently going on. Sign off isn't going to help here. Delivering a
running system every couple of weeks might, to some degree.

Take care, Ilja

Paul Sinnett wrote:
> Ilja Preuss wrote:
>> I'd rather say we know that we need to take care that management
>> expectations and customer expectations get aligned.
>>
>> Do you see anything in XP which would make this harder than using a
>> different process?
>
> I don't see anything in XP which deals with this at all.

Yes - besides Open Honest Communication, perhaps.

> That is, in Planning Extreme Programming we have the customer's bill
> of rights, and the programmer's bill of rights. But there's no
> manager's bill of rights. Maybe there needs to be one...

How would it differ from the Customer's bill of rights?

> What do you see as management's role within an XP project?

Basically:
- supporting the development team so that it effectively can provide
business value
- canceling the project when it can't provide business value

*How* it does that is probably *very* project dependent, so that I doubt
that XP should be very specific about this.

Cheers, Ilja

Randy:

> > Are you aware of any *software development process* that specifically
> > addresses the situation "where management requirements and customer
> > requirements aren't aligned"?
> 
> Yes, any development process that includes upfront requirements that are
> signed off by the customer and management has this alignment.

What if the upfront requirements that are signed off upon happen to be 
something that the customer doesn't, in fact, want ?

This appears to be a very, very common characteristic of software 
projects, perhaps second only to the case where no requirements are 
explicitly defined.

Laurent
http://bossavit.com/thoughts/

On Mon, 19 Apr 2004 23:23:32 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>> >> I'd rather say we know that we need to take care that management
>> >> expectations and customer expectations get aligned.
>> >>
>> >> Do you see anything in XP which would make this harder than using a
>> >> different process?
>> >
>> > I don't see anything in XP which deals with this at all.
>>
>> Are you aware of any *software development process* that specifically
>> addresses the situation "where management requirements and customer
>> requirements aren't aligned"?
>
>Yes, any development process that includes upfront requirements that are
>signed off by the customer and management has this alignment.  Whether the
>software team can deliver then becomes the issue.  Note that there may be
>valid reasons why the software development team can not deliver, but this
>does not negate the fact that the customer and management are aligned.

How does that work out if, as in the case of C3, all the management
structure above the project changes?

How does it work out if the market changes?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 20 Apr 2004 00:28:19 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>Ronald E Jeffries wrote:
>> What do you think?
>
>I think it all sounds very familiar.
>
>One thing still puzzles me though. If DC still want to replace their 
>legacy payroll with a single solution and are willing to pay through the 
>nose for it, why not restart C3? Starting afresh only adds to the number 
>of systems they will have to replace. Is it that they don't think C3 can 
>be extended?

C3 was taken back off line about four years after it deployed. And
there are no advocates for the program there. And they think that if
they "just" buy PeopleSoft, everything will be OK.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 19 Apr 2004 23:23:32 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>Jason,
>
>> >> I'd rather say we know that we need to take care that management
>> >> expectations and customer expectations get aligned.
>> >>
>> >> Do you see anything in XP which would make this harder than using a
>> >> different process?
>> >
>> > I don't see anything in XP which deals with this at all.
>>
>> Are you aware of any *software development process* that specifically
>> addresses the situation "where management requirements and customer
>> requirements aren't aligned"?
>
>Yes, any development process that includes upfront requirements that are
>signed off by the customer and management has this alignment.  Whether the
>software team can deliver then becomes the issue.  Note that there may be
>valid reasons why the software development team can not deliver, but this
>does not negate the fact that the customer and management are aligned.

This presumes that the act of "signing off" has meaning.  In most
cases it doesn't.  Customer's seldom know what they really want.  They
sign off on requirements because that's the only way to get the
development team moving.  If the delivered system meets the
requirements, but does not meet the customers need, the project will
have failed.

A process in which the customers and managers sign off on requirements
is not aligned to reality.  

In XP, as in any agile method, the customers, managers, developers,
QA, documentation, and all other team members continually realign
their expectations every iteration.  

 * Customers select what they want delivered in that iteration, based
on developer estimates.

 * QA specifies done-ness by writing automated acceptance tests.

 * Managers know what artifacts need to be delivered during the
iteration and what metrics to monitor.  

 * Developers know what features to work on, and report progress
against.

Alignment at this level simply cannot get very far out of whack in an
agile team.

If I understand it correctly, the cancellation of C3 was caused by a
misalignment between two different departments way up the management
chain.  Signed-off requirements would not have corrected that
mis-alignment because it wasn't about requirements at all.  The
problem was not the development process, it was the business process
at the top of the organization.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Mon, 19 Apr 2004 23:52:47 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>Ilja Preuss wrote:
>> I'd rather say we know that we need to take care that management
>> expectations and customer expectations get aligned.
>> 
>> Do you see anything in XP which would make this harder than using a
>> different process?
>
>I don't see anything in XP which deals with this at all.

That's odd.  One of the primary reasons for the short cycles and open
communications in XP is to get everybody's expectations realigned
every week or so.  This includes customers, managers, developers, etc.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Robert C. Martin wrote:
> On Mon, 19 Apr 2004 23:52:47 +0100, Paul Sinnett
> <paul.sinnett@btinternet.com> wrote:
>
>> Ilja Preuss wrote:
>>> I'd rather say we know that we need to take care that management
>>> expectations and customer expectations get aligned.
>>>
>>> Do you see anything in XP which would make this harder than using a
>>> different process?
>>
>> I don't see anything in XP which deals with this at all.
>
> That's odd.  One of the primary reasons for the short cycles and open
> communications in XP is to get everybody's expectations realigned
> every week or so.  This includes customers, managers, developers, etc.

Yes. But there is nothing in XP which guarantees that management actually
takes a look at the frequent deliveries.

Regards, Ilja

Jason Nocks wrote:
> Are you aware of any *software development process* that specifically 
> addresses the situation "where management requirements and customer 
> requirements aren't aligned"?

Yes. Barry Boehm's Theory-W + Spiral Lifecycle.

> <paul.sinnett@btinternet.com> wrote:
>> Or maybe it would be better to use Spiral if conflicting interests
>> seem likely, and save XP for those project where this risk cannot
>> occur - such as when the customers and management are the same
>> people, or the developers and management are the same people?

Ronald E Jeffries wrote:
> What do you see as the important difference between Spiral and XP in 
> this regard? XP delivers running tested software in priority order, 
> visible to all concerned. What does Spiral do, in your view, that is 
> better?

I don't know enough about it to have any views on that yet. But from 
what I have read, Boehm's approach is directly targeted at resolving 
such conflicts, whereas XP requires that there be none. Or so it seems 
from our discussion so far.

Ronald E Jeffries wrote:
> C3 was taken back off line about four years after it deployed. And 
> there are no advocates for the program there.

Ah, I was under the impression that the C3 code was still in use.

You say there are no advocates for C3 there, but Jeff said earlier:
> A few years later, I saw papers published as to what a great success 
> XP projects were having at DC.  They were quite proud of their 
> accomplishments.

Has XP fallen out of favour again at DC?

Ronald E Jeffries wrote:
> And they think that if they "just" buy PeopleSoft, everything will be
> OK.

Is this the project Chet was talking about on the wiki?:

  "Daimler Chrysler still wants to replace all of their payrolls systems
   with a single solution and are gearing up to spend about 4 times C3's
   total cost to do it. This will be Daimler Chrysler's fifth attempt to
   do this." -- Chet Hendrickson

> Robert C. Martin wrote:
>> That's odd.  One of the primary reasons for the short cycles and
>> open communications in XP is to get everybody's expectations
>> realigned every week or so.  This includes customers, managers,
>> developers, etc.

Ilja Preu� wrote:
> Yes. But there is nothing in XP which guarantees that management
> actually takes a look at the frequent deliveries.

And this appears to be at the root of the problem with C3 if I'm
reading Ron's descriptions correctly.

On Tue, 20 Apr 2004 19:20:01 +0200, "Ilja Preu�" <preuss@disy.net>
wrote:

>Robert C. Martin wrote:
>> On Mon, 19 Apr 2004 23:52:47 +0100, Paul Sinnett
>> <paul.sinnett@btinternet.com> wrote:
>>
>>> Ilja Preuss wrote:
>>>> I'd rather say we know that we need to take care that management
>>>> expectations and customer expectations get aligned.
>>>>
>>>> Do you see anything in XP which would make this harder than using a
>>>> different process?
>>>
>>> I don't see anything in XP which deals with this at all.
>>
>> That's odd.  One of the primary reasons for the short cycles and open
>> communications in XP is to get everybody's expectations realigned
>> every week or so.  This includes customers, managers, developers, etc.
>
>Yes. But there is nothing in XP which guarantees that management actually
>takes a look at the frequent deliveries.

There is nothing in any methodology that guarantees that managers will
do their job.  


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Wed, 21 Apr 2004 01:12:42 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>Ronald E Jeffries wrote:
>> C3 was taken back off line about four years after it deployed. And 
>> there are no advocates for the program there.
>
>Ah, I was under the impression that the C3 code was still in use.
>
>You say there are no advocates for C3 there, but Jeff said earlier:
>> A few years later, I saw papers published as to what a great success 
>> XP projects were having at DC.  They were quite proud of their 
>> accomplishments.
>
>Has XP fallen out of favour again at DC?

No, as a matter of fact in some sectors it is strongly recommended for
projects with highly variable or poorly understood requirements.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ilja,

> >> Are you aware of any *software development process* that specifically
> >> addresses the situation "where management requirements and customer
> >> requirements aren't aligned"?
> >
> > Yes, any development process that includes upfront requirements that
> > are signed off by the customer and management has this alignment.
>
> Sign off on a requirement documents doesn't guarantee alignement at all.
> Keep in mind that on the C3 project, the people canceling the project
> weren't even there when there could have been a sign off, as far as I
> understand.
>
> What I would want to have is both customers and management being aware of
> what's currently going on. Sign off isn't going to help here. Delivering a
> running system every couple of weeks might, to some degree.

Thanks for your point of view.  I appreciate it, but don't agree.
Management often pays for the product being developed and thereby is very
interested in sign-off and alignment.

I have never been in a situation where management wasn't at least one of my
customers.  It seems like they (management) are everywhere.  Pardon the
humor, but the point is that good management (there is such a thing) is able
to do the cost versus benefits analysis.  Sizing up the C3 project can be
gamed into the right domain to fit ones beliefs, since there is really no
public data.  However, I think the following conclusions are warranted:

1.  Whether the people making the decisions were there to watch the entire
"free" part of the system (during OO exploration) development, the
management that made the final decision knows how to calculate ROI, ROR,
cost, benefits and productivity.  The initial investment (all the free work
during OO exploration) was at least considered in the analysis as a benefit.
They (management) are not as stupid as they look.

2.  Based on the cost, when it came time for someone to assume the project
expense, the benefits, even including the substantial initial investment and
progress, could not justify furtherance of the project.  I see every
motivation for management to leverage the initial investment and no
motivation to write that investment off, unless the analysis said that to
finish the system would cost much more than to create a new one a different
way.

3.  C3 was a research project that yielded no public disclosure of real data
documenting the costs, benefits or team productivity in any way that
satisfies my curiosity, which means I have to rely on the fact that everyone
knew what they were doing; including the software development team,
customers and management.  The odds are in my favor on this bet.

4.  XP should share a significant portion of the blame for yielding a
product that management (the customers) would not buy.  Certainly, if
management would have purchased the XP product, we would be hearing that it
was because of the terrific product that XP generated.

I know that these point will not be popular with many, but I believe they
are fair, impartial and probable, since I have no motivation that would lead
me to be otherwise.  If public data were available, then we might be able to
put a finer point on a few of these observations.

Regards,

Randy

Laurent,

> > > Are you aware of any *software development process* that specifically
> > > addresses the situation "where management requirements and customer
> > > requirements aren't aligned"?
> >
> > Yes, any development process that includes upfront requirements that are
> > signed off by the customer and management has this alignment.
>
> What if the upfront requirements that are signed off upon happen to be
> something that the customer doesn't, in fact, want ?
>
> This appears to be a very, very common characteristic of software
> projects, perhaps second only to the case where no requirements are
> explicitly defined.

By signing-off, the customer and management is saying that that is what they
want.  When the customer and/or management changes their mind, another
sign-off must occur.  Furthermore, sign-off can occur without requirements.
I have had several manager sign-off while exhibiting a lot of faith in the
team by saying, do what you think is best.-

<Humor>Sign-off certainly had to occur before 3X5 cards were invented!
<\Humor>

Regards,

Randy

Ron,

> >> Are you aware of any *software development process* that specifically
> >> addresses the situation "where management requirements and customer
> >> requirements aren't aligned"?
> >
> >Yes, any development process that includes upfront requirements that are
> >signed off by the customer and management has this alignment.  Whether
the
> >software team can deliver then becomes the issue.  Note that there may be
> >valid reasons why the software development team can not deliver, but this
> >does not negate the fact that the customer and management are aligned.
>
> How does that work out if, as in the case of C3, all the management
> structure above the project changes?

Another sign-off should occur.

> How does it work out if the market changes?

Sign-off on the reaction to market changes.

Regards,

Randy

Bob,

> >> Are you aware of any *software development process* that specifically
> >> addresses the situation "where management requirements and customer
> >> requirements aren't aligned"?
> >
> >Yes, any development process that includes upfront requirements that are
> >signed off by the customer and management has this alignment.  Whether
the
> >software team can deliver then becomes the issue.  Note that there may be
> >valid reasons why the software development team can not deliver, but this
> >does not negate the fact that the customer and management are aligned.
>
> This presumes that the act of "signing off" has meaning.  In most
> cases it doesn't.  Customer's seldom know what they really want.  They
> sign off on requirements because that's the only way to get the
> development team moving.  If the delivered system meets the
> requirements, but does not meet the customers need, the project will
> have failed.
>
> A process in which the customers and managers sign off on requirements
> is not aligned to reality.

If that were really a univeral law, then a lot of software that has been
built would not have been built.

Certainly customers change their minds.  But those changes have more to do
with the details of an approach or presentation rather than the general goal
of the software being built.  I have never encountered a situation where my
manager and customer signed-off on a real-time AI control software package
and then somewhere in the middle decided that they just wanted a data
logging, plotting and statistics package.  There has never been a situation
where I was asked to track a shipping container and afteward the customer
and management changed their mind to want a transport flight schedule
application.

That is why presuming that there is meaning in the sign-off and sign-off is
aligned to reality.

Regards,

Randy

Randy A. Ynchausti wrote:

>> Sign off on a requirement documents doesn't guarantee alignement at
>> all. Keep in mind that on the C3 project, the people canceling the
>> project weren't even there when there could have been a sign off, as
>> far as I understand.
>>
>> What I would want to have is both customers and management being
>> aware of what's currently going on. Sign off isn't going to help
>> here. Delivering a running system every couple of weeks might, to
>> some degree.
>
> Thanks for your point of view.  I appreciate it, but don't agree.
> Management often pays for the product being developed and thereby is
> very interested in sign-off and alignment.

I do fully understand that management is interested in alignment, and I
think they should be. I think that being confronted with a running system
and with the current Release Plan regularly is much more likely to help in
getting *and maintaining* alignment than sign-off.

> 4.  XP should share a significant portion of the blame for yielding a
> product that management (the customers) would not buy.  Certainly, if
> management would have purchased the XP product, we would be hearing
> that it was because of the terrific product that XP generated.

Well, with the same reasoning we could easily blame Smalltalk, the IDE they
used, SUnit etc. pp.?

Take care, Ilja

Randy A. Ynchausti wrote:

> Laurent,
> 
> 
>>>>Are you aware of any *software development process* that specifically
>>>>addresses the situation "where management requirements and customer
>>>>requirements aren't aligned"?
>>>
>>>Yes, any development process that includes upfront requirements that are
>>>signed off by the customer and management has this alignment.
>>
>>What if the upfront requirements that are signed off upon happen to be
>>something that the customer doesn't, in fact, want ?
>>
>>This appears to be a very, very common characteristic of software
>>projects, perhaps second only to the case where no requirements are
>>explicitly defined.
> 
> 
> By signing-off, the customer and management is saying that that is what they
> want.  When the customer and/or management changes their mind, another

No, by signing-off, the customer and management are indicating an 
acceptance of what they are "asking for", not "what they want". What 
customers want and what they ask for are often not in alignment, 
particularly at the start of a project.

Otherwise, coming up with a requirements document would be a simple 
matter of writing a straightforward document in a day or so. Why do 
plan-driven teams spend *months* coming up with requirements specifications?

Also, you are ignoring the example here. In this example, the GoalDonor 
*is* management, just not the highest level of management (GoldOwner). 
The highest level of management is not as intimately involved as the 
lower or middle management.

You have also conveniently ignored the fact that management was changed 
out (Chrysler became part of DaimlerChrysler IIRC). New management is 
almost guaranteed to reverse and change what is desired and even what is 
"asked for". When they change what is "asked for", great. However, it 
seems that the problem here is that new management did not change what 
was "asked for", but did change what was "wanted".

I was not involved in the project. This is just my $.02 based on what 
I've heard and read.

> sign-off must occur.  Furthermore, sign-off can occur without requirements.
> I have had several manager sign-off while exhibiting a lot of faith in the
> team by saying, do what you think is best.-

So, how does this guarantee alignment?

> Regards,
> 
> Randy

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Randy A. Ynchausti wrote:

> Bob,
> 
> 
>>>>Are you aware of any *software development process* that specifically
>>>>addresses the situation "where management requirements and customer
>>>>requirements aren't aligned"?
>>>
>>>Yes, any development process that includes upfront requirements that are
>>>signed off by the customer and management has this alignment.  Whether
> 
> the
> 
>>>software team can deliver then becomes the issue.  Note that there may be
>>>valid reasons why the software development team can not deliver, but this
>>>does not negate the fact that the customer and management are aligned.
>>
>>This presumes that the act of "signing off" has meaning.  In most
>>cases it doesn't.  Customer's seldom know what they really want.  They
>>sign off on requirements because that's the only way to get the
>>development team moving.  If the delivered system meets the
>>requirements, but does not meet the customers need, the project will
>>have failed.
>>
>>A process in which the customers and managers sign off on requirements
>>is not aligned to reality.
> 
> If that were really a univeral law, then a lot of software that has been
> built would not have been built.

Actually, it would be straightforward to suspect that it would result in 
a lot of software that gets built and then remains unused, or considered 
to be a failure. This is consistent with studies that demonstrate 
something like 75% failure rates, etc.

I used to work for a consulting company a few years back that did 
heavily plan-based software development. The customers signed off on 
Functional Requirements Specs, Detailed Design Documents, etc. The 
majority of the projects were completed as spec'd. The consulting 
company considered these to be successful projects. The majority were 
never put into use at all. Curiously, there was also nothing in the 
process to gather feedback as to whether or not the projects made it 
into production and why if not. Different projects probably had 
different reasons for not being used by the customers, but in my 
opinion, a disparity between what was desired and what was asked for 
seemed to be a *very* common theme.

I'd like to continue to deliver working, tested software that actually 
gets used. To me, this requires actually delivering what is desired (or 
as close as we can get within the budget), rather than what was 
initially asked for. To me, Agile processes generally acknowledge and 
directly address this issue.

> Certainly customers change their minds.  But those changes have more to do

This may actually have less to do with a customer changing their mind 
and more to do with not being able to convey what they want, or not 
realizing what they are actually asking for. Often, customers don't know 
*exactly* what they want until they see it. I've been on both sides of 
this issue.

There's an old poem floating around the 'net, it's a parody set along 
the lines of "The Night Before Christmas". The version I've seen is 
called something like "The Night Before Release". The last line goes 
something like the following:

"IT'S JUST WHAT WE ASKED FOR, BUT NOT WHAT WE WANT"

> with the details of an approach or presentation rather than the general goal
> of the software being built.  I have never encountered a situation where my
> manager and customer signed-off on a real-time AI control software package
> and then somewhere in the middle decided that they just wanted a data
> logging, plotting and statistics package.  There has never been a situation
> where I was asked to track a shipping container and afteward the customer
> and management changed their mind to want a transport flight schedule
> application.
> 
> That is why presuming that there is meaning in the sign-off and sign-off is
> aligned to reality.
> 
> Regards,
> 
> Randy

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Paul Sinnett wrote:

> Jason Nocks wrote:
> 
>> Are you aware of any *software development process* that specifically 
>> addresses the situation "where management requirements and customer 
>> requirements aren't aligned"?
> 
> 
> Yes. Barry Boehm's Theory-W + Spiral Lifecycle.

I'm not very familiar with these particulars. Do they address the 
situation where the direct customer is lying to the higher levels of 
management about what is actually being done?

If so, can you please explain how? Thanks.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Robert C. Martin wrote:

> On Tue, 20 Apr 2004 19:20:01 +0200, "Ilja Preu�" <preuss@disy.net>
> wrote:
> 
>>Robert C. Martin wrote:
>>
>>>On Mon, 19 Apr 2004 23:52:47 +0100, Paul Sinnett
>>><paul.sinnett@btinternet.com> wrote:
>>>
>>>>I don't see anything in XP which deals with this at all.
>>>
>>>That's odd.  One of the primary reasons for the short cycles and open
>>>communications in XP is to get everybody's expectations realigned
>>>every week or so.  This includes customers, managers, developers, etc.
>>
>>Yes. But there is nothing in XP which guarantees that management actually
>>takes a look at the frequent deliveries.
> 
> There is nothing in any methodology that guarantees that managers will
> do their job.  

Nor, that the developers will either :)

Sometimes I sound like the guy in "Soylent Green" when I start ranting 
about "Software development is people..."

> -----
> Robert C. Martin (Uncle Bob)
> Object Mentor Inc.
> unclebob @ objectmentor . com
> 800-338-6716
> 
> "Distinguishing between the author
> and the writing is the essence of civilized debate."
>            -- Daniel Parker

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<sep2801gvrbsfea69ecdlif9o0qhkdu45n@4ax.com>...

From what has been written in this discussion, we'd have to assume
that whatever the development team understood by project success was
different to what the management stakeholders understood by project
success.

1. Lack of clear link between the project
   and the organisation's key strategic
   priorities, including agreed measures
   of success.

(From "The Challenges of Complex IT Projects" posting)

-snip-
> So we had a project which was delivering what it said it could, when
> it said it could, all running, all tested, all confirmed against the
> existing payroll. The information the project had was blocked by
> management from going where it needed to go. It was certainly not the
> best possible result, but it was also outside the scope of most any
> software development method. Still bad, I'm not saying that it wasn't.
> But was it a problem with XP, or with people outside the XP purview? I
> believe the latter. Still bad, though.
> 
> What do you think?

Are we saying that the project shipped code on the development team's
schedule but not on the management team's schedule?

Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<d144b$40869700$cff54506$2124@dcanet.allthenewsgroups.com>...

> There's an old poem floating around the 'net, it's a parody set along 
> the lines of "The Night Before Christmas". 

It's already been applied to C3 in this discussion:
http://groups.google.com/groups?q=g:thl1422561443d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=40805f1f%40news.totallyobjects.com&rnum=8

On 21 Apr 2004 12:08:38 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Are we saying that the project shipped code on the development team's
>schedule but not on the management team's schedule?

Sort of. But complaining about that would be like complaining that the
weather at the wedding didn't meet the bride's plans.

The point of XP is that the team throws off solid, predictable
progress in a visible fashion, and management can steer the project,
or terminate it, with a lot of clarity.

The truth was stopped from rising up the hierarchy, until of course,
magic dates came and went.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<evbe8094o8m0l0eo5im2j2tfio5ljffjt4@4ax.com>...

> >Are we saying that the project shipped code on the development team's
> >schedule but not on the management team's schedule?
> 
> Sort of. But complaining about that would be like complaining that the
> weather at the wedding didn't meet the bride's plans.
> 
> The point of XP is that the team throws off solid, predictable
> progress in a visible fashion, and management can steer the project,
> or terminate it, with a lot of clarity.
> 
> The truth was stopped from rising up the hierarchy, until of course,
> magic dates came and went.

We seem to be saying they should have cancelled the project earlier -
but the truth about the project wasn't reaching the decision makers?

Isaac Gouy wrote:
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message

>> The truth was stopped from rising up the hierarchy, until of course,
>> magic dates came and went.
>
> We seem to be saying they should have cancelled the project earlier -
> but the truth about the project wasn't reaching the decision makers?

Cancelling it earlier would probably have been better - but I'd guess there
might have been other options earlier in development, such as changing the
scope of the project.

Cheers, Ilja

Isaac Gouy wrote:

> Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<d144b$40869700$cff54506$2124@dcanet.allthenewsgroups.com>...
> 
>>There's an old poem floating around the 'net, it's a parody set along 
>>the lines of "The Night Before Christmas". 
> 
> It's already been applied to C3 in this discussion:
> http://groups.google.com/groups?q=g:thl1422561443d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=40805f1f%40news.totallyobjects.com&rnum=8

Thanks, now if only I could refactor my post to eliminate this 
duplication...

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<evbe8094o8m0l0eo5im2j2tfio5ljffjt4@4ax.com>...
> On 21 Apr 2004 12:08:38 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
> 
> >Are we saying that the project shipped code on the development team's
> >schedule but not on the management team's schedule?
> 
> Sort of. But complaining about that would be like complaining that the
> weather at the wedding didn't meet the bride's plans.

In your view, which (if any) of the 8 "Common Causes of Project
Failure" did XP address on the C3 project?

>> Ilja Preuss wrote:
>>> I'd rather say we know that we need to take care that management 
>>> expectations and customer expectations get aligned.
>>> 
>>> Do you see anything in XP which would make this harder than using
>>> a different process?

> Paul Sinnett wrote:
>> I don't see anything in XP which deals with this at all.

Ilja Preu� wrote:
> Yes - besides Open Honest Communication, perhaps.

Perhaps, if the 'whole team' concept were to include management?

On Thu, 22 Apr 2004 20:30:09 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>>> Ilja Preuss wrote:
>>>> I'd rather say we know that we need to take care that management 
>>>> expectations and customer expectations get aligned.
>>>> 
>>>> Do you see anything in XP which would make this harder than using
>>>> a different process?
>
>> Paul Sinnett wrote:
>>> I don't see anything in XP which deals with this at all.
>
>Ilja Preu� wrote:
>> Yes - besides Open Honest Communication, perhaps.
>
>Perhaps, if the 'whole team' concept were to include management?

It does.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

>>> Paul Sinnett wrote:
>>>> I don't see anything in XP which deals with this at all.

>> Ilja Preu� wrote:
>>> Yes - besides Open Honest Communication, perhaps.

> Paul Sinnett wrote:
>> Perhaps, if the 'whole team' concept were to include management?

Robert C. Martin wrote:
> It does.

Then I still don't see anything which deals with it.

In summary:
Open honest communication within an inclusive team ought to avoid the
risk of customer and management expectations getting out of alignment.
But, in practice, conflicts of interest within the team override the
areas of our process that allow us to avoid this risk.

Is that a fair summary?

>> Jason Nocks wrote:
>>> Are you aware of any *software development process* that 
>>> specifically addresses the situation "where management 
>>> requirements and customer requirements aren't aligned"?

> Paul Sinnett wrote:
>> Yes. Barry Boehm's Theory-W + Spiral Lifecycle.

Jason Nocks wrote:
> I'm not very familiar with these particulars. Do they address the 
> situation where the direct customer is lying to the higher levels of 
> management about what is actually being done?
> 
> If so, can you please explain how? Thanks.

Theory-W was designed (as I understand it) to address the conflicts of
interest that often decay into the situation you describe.

Briefly, it is an application of game theory to the management of
conflicting interests within software projects. The parties develop a
mix of strategies that approximate a Nash equilibrium: no one
party can improve their own interests by switching strategy.

So, in your example, if the customer's strategy was such that he gains
nothing by lying to upper management you will have avoided much of that
risk.

Theory-W isn't a software development process in itself. But it was
designed (again, as I understand it) to work with the Spiral Lifecycle
Model; which is.

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c60pca$6ci$1@stu1id2.ip.tesion.net...
| Randy at Home wrote:
| > "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
| > news:uf1580597kkpkq9i4gdvjhjvkqouqc8fuq@4ax.com...
| >> On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
| >> <randy_ynchausti@msn.com> wrote:
| >>
| >>> Ron,
| >>>
| >>>>>> The upward management people weren't on our team, but somehow
| >>>>>> they must not have been getting what they wanted.
| >>>
| >>>> Yes, sort of, though in fact I think it /was/ largely what the
| >>>> customer wanted, but not what some upper-level folks wanted.
| >>>
| >>> This is truely the irony of extreme programming.
| >>
| >> This is truly the irony of programming.
| >
| > But how do you get anyone in the upper-levels to sign off on anything
| > other than adopting a methodology?
|
| What does "signing off" have to do with it?
|
| Confused, Ilja

I'm guessing you don't work on large enough projects where bills actually
have to get paid. Signing off on requirements, whether XP-ers like it or
not, contributes to getting budgets approved. The line item on the financial
statement where $100,000,000 gets spent has to mean something to the people
who are going to spend it.

Randy at Home wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:c60pca$6ci$1@stu1id2.ip.tesion.net...
>> Randy at Home wrote:
>>> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>>> news:uf1580597kkpkq9i4gdvjhjvkqouqc8fuq@4ax.com...
>>>> On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
>>>> <randy_ynchausti@msn.com> wrote:
>>>>
>>>>> Ron,
>>>>>
>>>>>>>> The upward management people weren't on our team, but somehow
>>>>>>>> they must not have been getting what they wanted.
>>>>>
>>>>>> Yes, sort of, though in fact I think it /was/ largely what the
>>>>>> customer wanted, but not what some upper-level folks wanted.
>>>>>
>>>>> This is truely the irony of extreme programming.
>>>>
>>>> This is truly the irony of programming.
>>>
>>> But how do you get anyone in the upper-levels to sign off on
>>> anything other than adopting a methodology?
>>
>> What does "signing off" have to do with it?
>>
>> Confused, Ilja
>
> I'm guessing you don't work on large enough projects where bills
> actually have to get paid.

You are not very good at guessing, so it seems to me. Perhaps asking
questions would be more effective.

> Signing off on requirements, whether
> XP-ers like it or not, contributes to getting budgets approved.

Perhaps. Though, as far as I know (I am not responsible for formulating
contracts or getting them signed), our contracts are often rather rough
outlines of what needs to get developed, and details are communicated during
development.

> The
> line item on the financial statement where $100,000,000 gets spent
> has to mean something to the people who are going to spend it.

Probably, yes.

I don't see at all how this is connected to alignement of expectations,
though.

Take care, Ilja

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6aj8p$25e$1@stu1id2.ip.tesion.net...
| Randy at Home wrote:
| > "Ilja Preu�" <preuss@disy.net> wrote in message
| > news:c60pca$6ci$1@stu1id2.ip.tesion.net...
| >> Randy at Home wrote:
| >>> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
| >>> news:uf1580597kkpkq9i4gdvjhjvkqouqc8fuq@4ax.com...
| >>>> On Sat, 17 Apr 2004 22:18:46 -0600, "Randy A. Ynchausti"
| >>>> <randy_ynchausti@msn.com> wrote:
| >>>>
| >>>>> Ron,
| >>>>>
| >>>>>>>> The upward management people weren't on our team, but somehow
| >>>>>>>> they must not have been getting what they wanted.
| >>>>>
| >>>>>> Yes, sort of, though in fact I think it /was/ largely what the
| >>>>>> customer wanted, but not what some upper-level folks wanted.
| >>>>>
| >>>>> This is truely the irony of extreme programming.
| >>>>
| >>>> This is truly the irony of programming.
| >>>
| >>> But how do you get anyone in the upper-levels to sign off on
| >>> anything other than adopting a methodology?
| >>
| >> What does "signing off" have to do with it?
| >>
| >> Confused, Ilja

<snip>

| > Signing off on requirements, whether
| > XP-ers like it or not, contributes to getting budgets approved.
|
| Perhaps. Though, as far as I know (I am not responsible for formulating
| contracts or getting them signed), our contracts are often rather rough
| outlines of what needs to get developed, and details are communicated
during
| development.

That's where the alignment typically goes wrong. The contracts must be
formulated in such a way as to make the methodology selected independent of
the deliverables - at least the contracted deliverables. I agree that the
details are left to the development, but to whom are they being communicated
and what is being communicated? Are these deviations from the contracted
deliverables? If so, the people who signed the contract had better be
involved, because you'll get out of alignment.

My point earlier was (restated) that if a set of deliverables are not
quantified in the contact, you have nothing to align to. The other party is
simply signing off on a good "head patting" and assuming that you will
deliver a system that does "something unspecified". I'm not suggesting that
the deliverables be fully specified; far from it. Pres. Kennedy specified a
really clear goal - Get a person to the moon in 10 years and return safely.
That is one of the best, clearly stated deliverables in history. The details
were left to the implementors, as it should be. We rarely get that kind of
clarity in software development, and that's part of the problem.

Managing expectations at a senior management level is critical to being able
to play in the XP pool. It's hard to swallow being told, after a year of
delivering stuff that *a subset* of your customers - you know, the ones
you're working with - wants,  only to have the budget rug pulled out for
non-delivery of what the *COMPANY* really needs.

Now the management of contracts is also subject to iterative processes. I
have yet to see clearly stated high-level goals coming from a company that
don't get changed at some point during development. How would you manage
those changes? Iteratively, perhaps? Good, but each change at a contract
level costs real money, and that needs to be managed.

For someone in a position of technical leadership that is using any
iterative methodology to go into this blind of money issues is not only
imprudent, it's irresponsible. That applies equally to traditional waterfall
approaches as well; which, I suspect is Robert's point also.

| > The
| > line item on the financial statement where $100,000,000 gets spent
| > has to mean something to the people who are going to spend it.
|
| Probably, yes.
|
| I don't see at all how this is connected to alignement of expectations,
| though.

Expectation #1: I'm going to get something I need for the money I'm
spending.

If you can't satisfy, or are perceived as not being able to satisfy that,
your $100,000,000 will dry up really fast.

Randy at Home wrote:

>>> Signing off on requirements, whether
>>> XP-ers like it or not, contributes to getting budgets approved.
>>
>> Perhaps. Though, as far as I know (I am not responsible for
>> formulating contracts or getting them signed), our contracts are
>> often rather rough outlines of what needs to get developed, and
>> details are communicated during development.
>
> That's where the alignment typically goes wrong. The contracts must be
> formulated in such a way as to make the methodology selected
> independent of the deliverables - at least the contracted
> deliverables.

I think I don't understand that last sentence.

> I agree that the details are left to the development,
> but to whom are they being communicated and what is being
> communicated? Are these deviations from the contracted deliverables?
> If so, the people who signed the contract had better be involved,
> because you'll get out of alignment.

All those who are interested in the outcome of the project need to be
involved, or need to trust those who are involved - wether they signed
anything or not.

> My point earlier was (restated) that if a set of deliverables are not
> quantified in the contact, you have nothing to align to.

You'd have the already developed deliverables and the current Release Plan,
or so it seems to me.

> The other
> party is simply signing off on a good "head patting" and assuming
> that you will deliver a system that does "something unspecified".

No, not something "unspecified", but something that gets more specified
during development.

> I'm
> not suggesting that the deliverables be fully specified; far from it.

C3 certainly had sign-off on "develop a payroll system".

> Pres. Kennedy specified a really clear goal - Get a person to the
> moon in 10 years and return safely. That is one of the best, clearly
> stated deliverables in history. The details were left to the
> implementors, as it should be. We rarely get that kind of clarity in
> software development, and that's part of the problem.

What if after 5 years, the "developers" found out that they probably
couldn't get a person to the moon in another 5 years - but some manager in
between them and the president didn't forward that information? How does
sign-off help in that situation?


> Managing expectations at a senior management level is critical to
> being able to play in the XP pool. It's hard to swallow being told,
> after a year of delivering stuff that *a subset* of your customers -
> you know, the ones you're working with - wants,  only to have the
> budget rug pulled out for non-delivery of what the *COMPANY* really
> needs.

Yes - but IDSHSOHH (I don't see how sign-off helps here).

> Now the management of contracts is also subject to iterative
> processes. I have yet to see clearly stated high-level goals coming
> from a company that don't get changed at some point during
> development. How would you manage those changes? Iteratively,
> perhaps? Good, but each change at a contract level costs real money,
> and that needs to be managed.

Of course every change needs to be managed (and if changes on the contract
level are much more costly, I would possibly tend to write less into the
contract). IDSHSOHH.

> For someone in a position of technical leadership that is using any
> iterative methodology to go into this blind of money issues is not
> only imprudent, it's irresponsible.

Yes. Again IDSHSOHH.

>>> The
>>> line item on the financial statement where $100,000,000 gets spent
>>> has to mean something to the people who are going to spend it.
>>
>> Probably, yes.
>>
>> I don't see at all how this is connected to alignement of
>> expectations, though.
>
> Expectation #1: I'm going to get something I need for the money I'm
> spending.
>
> If you can't satisfy, or are perceived as not being able to satisfy
> that, your $100,000,000 will dry up really fast.

Maybe sign-off will help you being perceived that way at the time of
sign-off - is that your point?

Puzzled, Ilja

On Thu, 22 Apr 2004 20:30:09 +0100, Paul Sinnett
<paul.sinnett@btinternet.com> wrote:

>>> Ilja Preuss wrote:
>>>> I'd rather say we know that we need to take care that management 
>>>> expectations and customer expectations get aligned.
>>>> 
>>>> Do you see anything in XP which would make this harder than using
>>>> a different process?
>
>> Paul Sinnett wrote:
>>> I don't see anything in XP which deals with this at all.
>
>Ilja Preu� wrote:
>> Yes - besides Open Honest Communication, perhaps.
>
>Perhaps, if the 'whole team' concept were to include management?

It includes all stakeholders. In the C3 case, the development manager,
who sat with us, explicitly said, in my hearing, that he could not
tell his boss the truth about the schedule. That the result was
abruptly bad does not, in retrospect, surprise me.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6bj47$395$1@stu1id2.ip.tesion.net...
| Randy at Home wrote:
|
| >>> Signing off on requirements, whether
| >>> XP-ers like it or not, contributes to getting budgets approved.
| >>
| >> Perhaps. Though, as far as I know (I am not responsible for
| >> formulating contracts or getting them signed), our contracts are
| >> often rather rough outlines of what needs to get developed, and
| >> details are communicated during development.
| >
| > That's where the alignment typically goes wrong. The contracts must be
| > formulated in such a way as to make the methodology selected
| > independent of the deliverables - at least the contracted
| > deliverables.
|
| I think I don't understand that last sentence.
|
| > I agree that the details are left to the development,
| > but to whom are they being communicated and what is being
| > communicated? Are these deviations from the contracted deliverables?
| > If so, the people who signed the contract had better be involved,
| > because you'll get out of alignment.
|
| All those who are interested in the outcome of the project need to be
| involved, or need to trust those who are involved - wether they signed
| anything or not.
|
| > My point earlier was (restated) that if a set of deliverables are not
| > quantified in the contact, you have nothing to align to.
|
| You'd have the already developed deliverables and the current Release
Plan,
| or so it seems to me.
|
| > The other
| > party is simply signing off on a good "head patting" and assuming
| > that you will deliver a system that does "something unspecified".
|
| No, not something "unspecified", but something that gets more specified
| during development.
|
| > I'm
| > not suggesting that the deliverables be fully specified; far from it.
|
| C3 certainly had sign-off on "develop a payroll system".

Good. And if that's enough, great. I doubt it was, though.

| > Pres. Kennedy specified a really clear goal - Get a person to the
| > moon in 10 years and return safely. That is one of the best, clearly
| > stated deliverables in history. The details were left to the
| > implementors, as it should be. We rarely get that kind of clarity in
| > software development, and that's part of the problem.
|
| What if after 5 years, the "developers" found out that they probably
| couldn't get a person to the moon in another 5 years - but some manager in
| between them and the president didn't forward that information? How does
| sign-off help in that situation?

That's an interesting speculation. The president would be at fault, because
it's always the leader's responsibility, to ensure that the people below
provide the information. No, a sign-off wouldn't help if the president
wasn't able to manage the information flow. But would the president give any
concern to whether it was a rocket or a space-plane that got there?

| > Managing expectations at a senior management level is critical to
| > being able to play in the XP pool. It's hard to swallow being told,
| > after a year of delivering stuff that *a subset* of your customers -
| > you know, the ones you're working with - wants,  only to have the
| > budget rug pulled out for non-delivery of what the *COMPANY* really
| > needs.
|
| Yes - but IDSHSOHH (I don't see how sign-off helps here).
|
| > Now the management of contracts is also subject to iterative
| > processes. I have yet to see clearly stated high-level goals coming
| > from a company that don't get changed at some point during
| > development. How would you manage those changes? Iteratively,
| > perhaps? Good, but each change at a contract level costs real money,
| > and that needs to be managed.
|
| Of course every change needs to be managed (and if changes on the contract
| level are much more costly, I would possibly tend to write less into the
| contract). IDSHSOHH.
|
| > For someone in a position of technical leadership that is using any
| > iterative methodology to go into this blind of money issues is not
| > only imprudent, it's irresponsible.
|
| Yes. Again IDSHSOHH.
|
| >>> The
| >>> line item on the financial statement where $100,000,000 gets spent
| >>> has to mean something to the people who are going to spend it.
| >>
| >> Probably, yes.
| >>
| >> I don't see at all how this is connected to alignement of
| >> expectations, though.
| >
| > Expectation #1: I'm going to get something I need for the money I'm
| > spending.
| >
| > If you can't satisfy, or are perceived as not being able to satisfy
| > that, your $100,000,000 will dry up really fast.
|
| Maybe sign-off will help you being perceived that way at the time of
| sign-off - is that your point?
|
| Puzzled, Ilja

No that's not the point. Let's suppose your C3 "develop a payroll system"
went through development and the end-user, your customer (?!) decided that
it wasn't a payroll system that was needed, but a project management system.
So, the requirements get re-done, and you head off merrily developing and
refactoring and doing whatever it is you do, and deliver the system on time
and on budget. But it's not a payroll system. It's a project management
system. What have you accomplished?

1. You delivered something valuable to your direct customer.
2. You delivered nothing to the people paying the bills.
3. You violated the terms of the project. Who owns the project charter? You
and your direct customer or senior management?
4. You probably will have really upset the people who are in a position to
sign your paycheck.

Is this, in your opinion, a good thing or a bad thing?

And

5. Is the company ahead? Possibly. Possibly not. But is it for you to
decide? IMHO it's insubordination at the very least.

The sign-off is done on a statement of what you're supposed to be working
on, and the boundaries.

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6bj47$395$1@stu1id2.ip.tesion.net...
> Randy at Home wrote:
>
> ....snippage ....
>
> All those who are interested in the outcome of the project need to be
> involved, or need to trust those who are involved - wether they signed
> anything or not.
>
> > My point earlier was (restated) that if a set of deliverables are not
> > quantified in the contact, you have nothing to align to.
>
> You'd have the already developed deliverables and the current Release
Plan,
> or so it seems to me.
>

I'm puzzled about how it is that you'd have done any development work
('developed deliverables') prior to having either a signed contract or
an approved, agreed project. Who paid for the work?

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<j0ki80pb4p214usj7c13c03ulsp1tqq13d@4ax.com>...

> >Ilja Preu� wrote:
> >> Yes - besides Open Honest Communication, perhaps.
> >
> >Perhaps, if the 'whole team' concept were to include management?
> 
> It includes all stakeholders. In the C3 case, the development manager,
> who sat with us, explicitly said, in my hearing, that he could not
> tell his boss the truth about the schedule. That the result was
> abruptly bad does not, in retrospect, surprise me.

Presumably "his boss" was a stakeholder - and at that point there was
a blatant lack of "Open Honest Communication"?

Randy at Home wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:c6bj47$395$1@stu1id2.ip.tesion.net...
>> Randy at Home wrote:

>>> Pres. Kennedy specified a really clear goal - Get a person to the
>>> moon in 10 years and return safely. That is one of the best, clearly
>>> stated deliverables in history. The details were left to the
>>> implementors, as it should be. We rarely get that kind of clarity in
>>> software development, and that's part of the problem.
>>
>> What if after 5 years, the "developers" found out that they probably
>> couldn't get a person to the moon in another 5 years - but some
>> manager in between them and the president didn't forward that
>> information? How does sign-off help in that situation?
>
> That's an interesting speculation. The president would be at fault,
> because it's always the leader's responsibility, to ensure that the
> people below provide the information.

So, was it the fault of the top managers at Chrysler that they didn't get
the correct information?

> No, a sign-off wouldn't help if
> the president wasn't able to manage the information flow. But would
> the president give any concern to whether it was a rocket or a
> space-plane that got there?

I don't know, and I don't see the connection to this thread.

> Let's suppose your C3 "develop a payroll
> system" went through development and the end-user, your customer (?!)
> decided that it wasn't a payroll system that was needed, but a
> project management system. So, the requirements get re-done, and you
> head off merrily developing and refactoring and doing whatever it is
> you do,

.... including showing upper management the updated release plan ...

> and deliver the system on time and on budget. But it's not a
> payroll system. It's a project management system. What have you
> accomplished?
>
> 1. You delivered something valuable to your direct customer.
> 2. You delivered nothing to the people paying the bills.

Then they should have stopped the project earlier. Sign-off didn't seem to
help in this case, did it?


> The sign-off is done on a statement of what you're supposed to be
> working on, and the boundaries.

Yes. I agree that you need that statement, that you need everyone to
understand that statement, and that you need to update that understanding
based on what happens. I don't think that sign-off is necessary or even
likely to help much.

I would even even guess that sign-off could have had something to do with
the C3 manager "being unable" to tell upper management the truth about the
projects state - because it didn't align with what they had "signed off" on.

Cheers, Ilja

Scott Kinney wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:c6bj47$395$1@stu1id2.ip.tesion.net...
>> Randy at Home wrote:
>>
>> ....snippage ....
>>
>> All those who are interested in the outcome of the project need to be
>> involved, or need to trust those who are involved - wether they
>> signed anything or not.
>>
>>> My point earlier was (restated) that if a set of deliverables are
>>> not quantified in the contact, you have nothing to align to.
>>
>> You'd have the already developed deliverables and the current
>> Release Plan, or so it seems to me.
>>
>
> I'm puzzled about how it is that you'd have done any development work
> ('developed deliverables') prior to having either a signed contract or
> an approved, agreed project. Who paid for the work?

The same one who pays for writing the requirements document that gets signed
off if you like to do that - someone who wants to know wether you can do the
project at reasonable costs. XP has an Exploration Phase for that, in which
the first Release Plan is agreed upon and Architectural Spikes are
developed.

But I don't think that the start of the project is the only point in time
critical for alignment. You need to readjust the alignment during the
project. That's where the current state of the running deliverables comes
into play.

Cheers, Ilja

igouy@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.0404190808.73e27cc1@posting.google.com>...
> "Ilja Preuss" <ilja.preuss@web.de> wrote in message news:<4082ded6@news.totallyobjects.com>...
 
> > But let's accept that they believed it to be true - do you have an idea on
> > why they did so? 
> 
> I can invent a bundle of rationalizations ;-)

Just for fun

"Gorillas in our midst: sustained inattentional blindness for dynamic events"
http://www.wjh.harvard.edu/~cfc/Simons1999.pdf

Ronald E Jeffries wrote:
> The Irony of Extreme Programming
> Ron Jeffries
> 04/12/2004
>
>   The irony of Extreme Programming is that while detractors continue
> to  explain why it cannot work, software developers all over the
world
> are having success with it.
>
>   http://www.xprogramming.com/xpmag/jatIronyOfXP.htm
>
> Enjoy ...
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for
you.