Discussion:
Day 2... From the author...
Bill Walton
2002-09-25 21:11:21 UTC
Permalink
Greetings all !

Your response has been wonderful, but I have to admit there's no way I can respond to all your postings individually. Rather than risk offending the majority of you by only responding to a minority, I'd like to restate my hope / objective for our discussion and, in doing so, to summarize where my understanding is based on the feedback / input you've given me as a group. I hope to capture the essence of what you've communicated. If I've missed it, please let me know. I hope you'll not be offended by this approach, but it's the best I can realistically shoot for. I think of it as an XP approach. There are just too many cards on my side of the pencil :-)

My concerns are about the business side of XP, not the technical side. I have to assume that I wasn't very clear on this either in the StickMinds column or in my postings to this forum since the majority of your postings / responses yesterday were oriented at educating me on the technical aspects / merits of XP. I have noted that quite a few of the postings today have begun to address the business side of things. I'm hoping this posting may accelerate that. When I talk about the business side of things, what I mean to talk about is change. Change to what? How can we make that change happen? What are the chief obstacles to the change we seek? These are questions that require business answers, not technicals answer. You'll note that, from my perspective, the problem is about effective communication.

--- Change to what? ---
I assume that the intent of this group is to see XP become mainstream practice. If that's an incorrect assumption, someone please tell me because, in that case, I'm wasting your time and mine. If that's not an incorrect assumption, they we need to start thinking about this as a marketing problem. When I say marketing, I mean communication. An effective "elevator speech" is a recognized prerequisite to getting more of an executive's time to continue the discussion about the need for any change. That elevator speech must get the mainstream listener's attention by talking about the benefits of change without raising red-flags in their mind about increased risk. XP lacks this today.

--- How can we make that change happen? ---
The most important rule of leading change, in my experience, is to make sure all the parties know and agree about all the relevant aspects of where things stand today. Without that agreement, there can never be agreement about what the first step should be or whether it's a step forward or not. XP addresses where things stand from the programmer's perspective very eloquently. But I've yet to see anything but a programmer's view of things. Back to management for a sec. We all know the waterfall / V model does not produce good results from a technical perspective. When I say all, I mean executives too. At least the ones I know, know. So my question is "what is it about that model that continues to provide value to the exec that the XP model lacks?" If there wasn't something "good" about it, they'd have dropped it long ago. It's no good to speculate. We need real data. Once we have it, we may not like the answer. I suspect they do not like it either. But until we a
sk the question and understand that answer, I can't forsee them accepting a change to XP on any scale.

--- What are the primary obstacles to the change we seek? ---
The world we work in today is dominated by intense scrutiny and legislation regarding the effectiveness of the CEO / CFO in their fiduciary oversight role. I can't imagine a CEO or CFO in any publicly-traded company today that isn't carefully examining every detail of how her company is being run for the possibility that it will get them into trouble (i.e., land them in jail). At the same time, XP is advocating practices that, at least by existing, generally accepted business practices, would be seen as reducing that oversight capability. I'm talking specifically about the card-based planning and reporting you've schooled me on. Anything that diminishes the exec's ability to fulfill her oversight responsibility, or makes it harder or more time consuming, is likely to get shot before it gets through the door.

XP's current overall argument, as I understand it after you've explained many of the details, still seems almost calculated to offend and alienate the entire management chain by making them, at best, ask for entrance and prove that they will provide value to the process above and beyond what programmers can do "on their own." It lacks an element of respect for our co-workers. While I don't remember addressing them specifically in our exchanges, let's take a sec to talk about project managers. They have a pretty widely recognized and valued role in the mainstream. XP takes the position that they're optional. XP seems to say to the project manager, we programmers can provide all the value you do with less overhead. And with no need for the training, etc. you've been through or for your experience. By virtue of that, it says to those managers, directors, VP's, etc. who have championed project management, project management certification, PMO's, etc. that they've wasted th
e company's time and money. It may not be what XP means to say, but it's what's coming across.

In addition, the hype that's been generated around XP is yielding who-knows-what conversations between programmers who want to do XP and their management? At the very least, I think the XP leadership needs to publish prominently, where execs would know about it and have ready access to it, a short list (not a book) of "here there be dragons." You need to give them a comfort level that they'll have the information they need when confronted with an enthusiastic, apparently knowledgeable, but wrong-headed employee who is liable, by your own estimation, to use XP in a way that will not likely yield good results. In short, you need to let them know you're not their enemy.

I'm sorry it's taken me so long to complete this to get it posted. One of my favorite Mark Twain quotes seems appropriate... "I'm sorry this note is so long. I didn't have time to make it shorter."

Best regards,
Bill


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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Fehskens, Len
2002-09-25 21:13:01 UTC
Permalink
Bill Walton writes:

>One of my favorite Mark Twain quotes seems appropriate... "I'm sorry this note is so long. I didn't have time to make it shorter."

Misattribution. It's much older than that. Blaise Pascal.

len.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-09-25 21:26:49 UTC
Permalink
Bill, I don't have time at the moment to respond to all of this, and there
are better people to do so, anyway. But I would like to raise a few points:

Bill Walton said:
> they we need to start thinking about this as a marketing
> problem. When I say marketing, I mean communication. An
> effective "elevator speech" is a recognized prerequisite to
> getting more of an executive's time to continue the
> discussion about the need for any change. That elevator
> speech must get the mainstream listener's attention by
> talking about the benefits of change without raising
> red-flags in their mind about increased risk. XP lacks this today.

This topic comes up in this group every month or so. Some suggestions on
how to present it better would be appreciated.

> We all know the waterfall / V model does not produce
> good results from a technical perspective. When I say all, I
> mean executives too. At least the ones I know, know. So my
> question is "what is it about that model that continues to
> provide value to the exec that the XP model lacks?" If there
> wasn't something "good" about it, they'd have dropped it long
> ago.

Well, there familiarity and inertia, too. Still, the point that the value
of XP needs to be presented effectively is true.

> At the same time, XP is advocating
> practices that, at least by existing, generally accepted
> business practices, would be seen as reducing that oversight
> capability. I'm talking specifically about the card-based
> planning and reporting you've schooled me on. Anything that
> diminishes the exec's ability to fulfill her oversight
> responsibility, or makes it harder or more time consuming, is
> likely to get shot before it gets through the door.

XP is doing no such thing. Any documentation that's necessary for the
business can be, and should be, produced. This documentation is
specifically scheduled the same way that programming is, as stories. The
"no documentation" of XP is that such documents are not relied on for
communication *within* the project.

- George

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 13:08:39 UTC
Permalink
Hi George,

----- On Wednesday, September 25, 2002 4:26 PM, George Dinwiddie wrote:

> > At the same time, XP is advocating
> > practices that, at least by existing, generally accepted
> > business practices, would be seen as reducing that oversight
> > capability. I'm talking specifically about the card-based
> > planning and reporting you've schooled me on. Anything that
> > diminishes the exec's ability to fulfill her oversight
> > responsibility, or makes it harder or more time consuming, is
> > likely to get shot before it gets through the door.
>
> XP is doing no such thing. Any documentation that's necessary for the
> business can be, and should be, produced. This documentation is
> specifically scheduled the same way that programming is, as stories. The
> "no documentation" of XP is that such documents are not relied on for
> communication *within* the project.

I've come to realize, through interaction with this group, that XP
practitioners, particularly those with real experience, are taking a much
more realistic approach to project communication than the position being
hyped in the press and programmers I've talked to and seen on this list. My
point is that there's a communication problem. Your last sentence is a good
example, and please don't take offense to this because it's meant entirely
in goodwill. When you say *within* the project, I think you mean "among the
programmers and those with whom they have direct interaction." My point is
that that leaves out a whole bunch of people who may consider themselves
part of the project, right up to the people who funded it and are
responsible for seeing that that money is spent wisely. Words matter.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 13:47:43 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> I've come to realize, through interaction with this group, that XP
> practitioners, particularly those with real experience, are taking a
much
> more realistic approach to project communication than the position
being
> hyped in the press and programmers I've talked to and seen on this
list. My

I keep hearing about how XP is hyped. I haven't seen the hype. I'm not
saying it's not there, just that I haven't seen it.

I truly need to understand what's out there, so that when I suggesting
XPish ideas to a client, I know what kinds of things they might have
been exposed to, which could prejudice them, so that I can communicate
with them more effectively with their background in mind.

Thus, It would be very helpful if someone could point me to the hype -
which magazines, web sites, etc. should I be reading to see the hype?

Kyle Cordes
www.kylecordes.com



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Charlie Poole
2002-09-26 18:45:10 UTC
Permalink
Bill,

> I've come to realize, through interaction with this group, that XP
> practitioners, particularly those with real experience, are taking a much
> more realistic approach to project communication than the position being
> hyped in the press and programmers I've talked to and seen on
> this list. My point is that there's a communication problem.

You may not care to address this, but I'll give you a chance.

Don't you think that by writing and publishing an article about a group
of folks without first interacting with them and learning a little about
what they do, you may have contributed to the communication problem
just a teeny bit?

Now I'm not an author, but I can imagine that as one you operate
under certain pressures. If there is something in the system that
makes it necessary for you to pay attention to other things than
accuracy of information in order to get published, I can see that
might influence your behavior. But it doesn't make me want to pay
much attention to anything I read in the same publication in the
future.

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 20:18:03 UTC
Permalink
Hi Charlie,

----- On Thursday, September 26, 2002 1:45 PM, Charlie Poole wrote:

> > I've come to realize, through interaction with this group, that XP
> > practitioners, particularly those with real experience, are taking a
much
> > more realistic approach to project communication than the position being
> > hyped in the press and programmers I've talked to and seen on
> > this list. My point is that there's a communication problem.
>
> You may not care to address this, but I'll give you a chance.
>
> Don't you think that by writing and publishing an article about a group
> of folks without first interacting with them and learning a little about
> what they do, you may have contributed to the communication problem
> just a teeny bit?

On the one hand, absolutely. On the other hand, I think I'm justified in
believing I should be able to get a good idea about what a new technology is
about without first becoming an expert. That's how busy people decide what
to spend their time on. It's a very simple ROI calculation. How I spend my
time is based on my perception of the liklihood that I'm going to get value
out of activity X vs. activity Y. I suspect you run your life the same way.
It's pretty basic.

When I first heard about XP in 2000, I was a manager, sometimes still called
on to act as a project manager, of a test automation group. I saw the write
ups in the trade literature, heard about it from programmers I know, etc.
It was clear that, at that point, XP said very little (i.e., appeared to
exclude) the roles of testers, project managers, and managers. Why would I
want to spend the money and time to find out more about a new techology that
said none of the roles I served provided value?

> Now I'm not an author, but I can imagine that as one you operate
> under certain pressures. If there is something in the system that
> makes it necessary for you to pay attention to other things than
> accuracy of information in order to get published, I can see that
> might influence your behavior. But it doesn't make me want to pay
> much attention to anything I read in the same publication in the
> future.

I don't believe I paid attention to things other than the accuracy of
information. I would agree, based on what I've learned here, that if I'd
digged deeper, I would have found that the information on the surface wasn't
as accurate or as complete as it should have been. If I'd misquoted from
the sites I used to make the points I made, I would be ashamed. I am not.
If I was writing a book or a treatise, I'd do more indepth research. I was
not. It was an Op / Ed piece.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 20:21:53 UTC
Permalink
On Thu, 2002-09-26 at 13:18, Bill Walton wrote:
>
> On the one hand, absolutely. On the other hand, I think I'm justified in
> believing I should be able to get a good idea about what a new technology is
> about without first becoming an expert. [...]
> I would agree, based on what I've learned here, that if I'd
> digged deeper, I would have found that the information on the surface wasn't
> as accurate or as complete as it should have been. If I'd misquoted from
> the sites I used to make the points I made, I would be ashamed. I am not.
> If I was writing a book or a treatise, I'd do more indepth research. I was
> not. It was an Op / Ed piece.

Could you please tell us what materials you used in the preparation of
your opinions? I would like the opportunity to help correct the sources
you blame for your mistaken impression of XP.

Thanks,

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-25 21:54:53 UTC
Permalink
Hi Bill,

> My concerns are about the business side of XP, not the technical
> side.

I think there are multiple business sides: the end users' business,
the user organization's business, and the development organization's
business. XP attends clearly and directly to the end users' business,
and somewhat less clearly and directly to the others.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Charlie Poole
2002-09-25 22:15:37 UTC
Permalink
Dale,

> > My concerns are about the business side of XP, not the technical
> > side.
>
> I think there are multiple business sides: the end users' business,
> the user organization's business, and the development organization's
> business. XP attends clearly and directly to the end users' business,
> and somewhat less clearly and directly to the others.

I could be wrong, but that may be a new thought. ;-)

It seems to me that the simplification XP applies to the various
businesses is useful in lots of situations, so long as we remember
that it is a simplification.

By asking ourselves how we would develop if we could encapsulate all
that messy customer/business stuff in one role, XP has come up with
the Customer and an entire planning process which successfully
ignores one part of the real world's complexity. That's why it works.

For the issue you bring up, we need to ask "How can we develop if
we are unable to encapsulate all that s2t in the Customer?" I don't
know the answer, but I'm guessing it involves more, not less
customer involvement. It might even need to draw on some of the
skills that business analysts typically exercise.

Just a thought.

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-25 22:35:23 UTC
Permalink
Hi Charlie,

> By asking ourselves how we would develop if we could encapsulate all
> that messy customer/business stuff in one role, XP has come up with
> the Customer and an entire planning process which successfully
> ignores one part of the real world's complexity. That's why it
> works.

Perhaps another reason it works is that sometimes that part of the
real world isn't so complex, in which case the planning process is
perfectly appropriate.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Phlip
2002-09-25 22:47:09 UTC
Permalink
Charlie Poole sez:

> It seems to me that the simplification XP applies to the various
> businesses is useful in lots of situations, so long as we remember
> that it is a simplification.
>
> By asking ourselves how we would develop if we could encapsulate all
> that messy customer/business stuff in one role, XP has come up with
> the Customer and an entire planning process which successfully
> ignores one part of the real world's complexity. That's why it works.
>
> For the issue you bring up, we need to ask "How can we develop if
> we are unable to encapsulate all that s2t in the Customer?" I don't
> know the answer, but I'm guessing it involves more, not less
> customer involvement. It might even need to draw on some of the
> skills that business analysts typically exercise.

Peter Merel said this recently:

"Before XP the managers could always blame the team. If the team's doing XP,
then the only ones who can be blamed are the managers. You had your chance,
mate. You didn't just flub it up once, you flubbed it up every two weeks. You
are nailed to the tree, mate."

Not really sure where he was going with that, besides restating the obvious.

--
Phlip
http://www.greencheese.org/SpringPicnicZero
-- Founding member of NuGWa -
Nudists for Global Warming --

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-25 23:27:19 UTC
Permalink
Hi Phlip,

> Peter Merel said this recently:
>
> "Before XP the managers could always blame the team. If the team's
> doing XP, then the only ones who can be blamed are the managers. You
> had your chance, mate. You didn't just flub it up once, you flubbed it
> up every two weeks. You are nailed to the tree, mate."

That's probably not the "elevator talk" Bill is looking for.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 02:25:08 UTC
Permalink
Hi Dale,

I've enjoyed your postings. Thanks for staying engaged. To your point, I
say "yep." My question to you (and to the rest of the group) is, why is
that? That's where my question about respect comes from. The impression
the XP position gives (I recognize that this that position is probably not
as homogenous as it seems from the outside) is that the one group is more
important than the others. I have a hard time with that.

Best regards,
Bill

----- Original Message -----
From: "Dale Emery" <***@dhemery.com>
To: <***@yahoogroups.com>
Sent: Wednesday, September 25, 2002 4:54 PM
Subject: [XP] Re: Day 2... From the author...


> Hi Bill,
>
> > My concerns are about the business side of XP, not the technical
> > side.
>
> I think there are multiple business sides: the end users' business,
> the user organization's business, and the development organization's
> business. XP attends clearly and directly to the end users' business,
> and somewhat less clearly and directly to the others.
>
> Dale
>
>
>
> To Post a message, send it to: ***@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 06:05:15 UTC
Permalink
Hi Bill,

> > XP attends clearly and directly to the end users' business, and
> > somewhat less clearly and directly to the others.
>
> I've enjoyed your postings. Thanks for staying engaged. To your
> point, I say "yep." My question to you (and to the rest of the
> group) is, why is that? That's where my question about respect
> comes from. The impression the XP position gives (I recognize that
> this that position is probably not as homogenous as it seems from
> the outside) is that the one group is more important than the
> others.

"One group is more important than the others" is one possible
interpretation, perhaps a common one.

I'd like you to apply Jerry Weinberg's Rule of Three Interpretations:
Can you think of at least two other plausible interpretations?

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 17:53:53 UTC
Permalink
Hi Dale,

----- On Thursday, September 26, 2002 1:05 AM, Dale Emery wrote:

> > > XP attends clearly and directly to the end users' business, and
> > > somewhat less clearly and directly to the others.
> >
> > I've enjoyed your postings. Thanks for staying engaged. To your
> > point, I say "yep." My question to you (and to the rest of the
> > group) is, why is that? That's where my question about respect
> > comes from. The impression the XP position gives (I recognize that
> > this that position is probably not as homogenous as it seems from
> > the outside) is that the one group is more important than the
> > others.
>
> "One group is more important than the others" is one possible
> interpretation, perhaps a common one.
>
> I'd like you to apply Jerry Weinberg's Rule of Three Interpretations:
> Can you think of at least two other plausible interpretations?
>
> Dale

More than that, but here's two.
1) XP is still growing. The current state of the practice reflects their
experience to date.
2) XP is only intended to address small projects in small environments.

Question is, what message does the XP community *intend* to send to the
world?

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Charlie Poole
2002-09-26 19:29:33 UTC
Permalink
Bill,

> Question is, what message does the XP community *intend* to send to the
> world?

I'm not sure we *have* a common intent. For a long time I thought
that was OK, but I'm not sure now.

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 13:31:51 UTC
Permalink
----- On Wednesday, September 25, 2002, Dale Emery wrote:

> Hi Bill,
>
> > My concerns are about the business side of XP, not the technical
> > side.
>
> I think there are multiple business sides: the end users' business,
> the user organization's business, and the development organization's
> business. XP attends clearly and directly to the end users' business,
> and somewhat less clearly and directly to the others.
>
> Dale
>

Until we began this conversation, I wasn't aware that XP attended to *any*
of the other's needs. I'm a project manager by both training and by my
nature, so I tend to apply the same simple set of rules to most
undertakings. We know that most IT projects that fail do so due to missed
or misunderstood requirements. Taking XP to the mainstream is just a
project, in my mind, where objective is to expand the audience for XP. How
will we succeed if we do not understand and address their requirements? I'm
suggesting that get some attention.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 13:58:17 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> undertakings. We know that most IT projects that fail do so due to
missed
> or misunderstood requirements. Taking XP to the mainstream is just a


I don't know this. It seems to me that while failure could be defined
as "did not meet requirements", the question of Why this happens has
lots of answers. I happened across this article, by Watts Humprey on
"Why Projects Fail":

http://www.computerworld.com/developmenttopics/development/story/0,10801
,71209,00.html

He lists 5 reasons, one of which is "Changing Requirements During
Development", and the others are not about requirements per se.


Kyle Cordes
www.kylecordes.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Christopher Hart
2002-09-25 21:55:38 UTC
Permalink
Bill,

The business side has at least as much, if not more, to gain as the
technical side. Screw change. We don't need change, we need communication
and communication does not take place in traditional software development.
XP is a communicative environment, and a lot of people are uncomfortable
with that because they they don't want to look stupid when they realize that
they aren't saying/doing what they mean/meant. Most people shoot for being
"unconscious competents" not "communicative competents". XP makes them jump
up a notch. XP will become mainstream practice in ten to fifteen years
unless we come up with a faster way to breakdown the traditional habits and
expectations.

The risks are all at the interpersonal level. XP practices reduce/eliminate
risk be getting rid of much of the uncertaintly and miscommunication that
currently occurs. Plus you have solid metrics to know exactly where the
project is and if it is meeting the business goals. There is transparency in
XP projects that no other methodology can even come close to, and it does it
without a ton of bureaucratic overhead that negatively impacts the bottom
line. When execs really come to understand what they get out of XP they are
going to demand XP practices in every project. Better be ready for that.

Best Regards,

Chris


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
kentlbeck
2002-09-25 22:03:42 UTC
Permalink
Before we get onto marketing to executives, I'd like to finish the
day 1 discussion a bit.

After listening a bit more, I read half of your article as
saying, "I was in this extremely valuable situation. I did something
other than what XP says. It worked. Therefore, this dog won't hunt."

Another tack to take is to say, "I'm not sure how XP would apply to
a one-month project sponsored by the CEO." You'd get a variety of
responses, but they'd all be around the theme of shorter iterations
(I'd choose 1 day) and continued business involvement (like the CEO
steering once a week and a business representative at the morning
stand-ups). I'd also inform the requirements discussion with
estimates during the initial two days.

The second half of the article (and your day 2 message) is about
marketing XP, part of which hinges on the seemingly impossible
requirement that business folks do their old job and act as members
of the project team at the same time, part of which hinges on how to
sell the shift of responsibility.

Re: whole team. Projects go better with real, day-to-day business
involvement. I say it. Standish says it (#1 on their list of
correlations with project success is customer involvement). I don't
think this is what we are debating. The question is whether business
is willing to pay the price. We certainly haven't done a good job of
communicating the benefits they can expect.

Re: selling the shift of responsibility. It is a trade. The
programmers offer transparency and control in return for business
accepting responsibility for scope. I'm stumped by how to
communicate this in an attractive way.

Kent




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 01:42:31 UTC
Permalink
From: "kentlbeck" <***@csi.com>

> After listening a bit more, I read half of your article as
> saying, "I was in this extremely valuable situation. I did something
> other than what XP says. It worked. Therefore, this dog won't hunt."

> Another tack to take is to say, "I'm not sure how XP would apply to
> a one-month project sponsored by the CEO." You'd get a variety of


Phrasing one's article this way, with reasonable and guarded
conclusions, does not get it published.

"<insert popular idea> is no good!!!" does get published.


Kyle Cordes
www.kylecordes.com



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 05:36:29 UTC
Permalink
Hi Kyle,

> Phrasing one's article this way, with reasonable and guarded
> conclusions, does not get it published.

StickyMinds publishes lots of reasonable and guarded conclusions,
phrased reasonably.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 11:52:22 UTC
Permalink
From: "Dale Emery" <***@dhemery.com>

> > Phrasing one's article this way, with reasonable and guarded
> > conclusions, does not get it published.

> StickyMinds publishes lots of reasonable and guarded conclusions,
> phrased reasonably.


My comment was a general one, not about StickyMinds in particular. In
general, it's easier to get published by taking a slightly controversial
position on a popular topic.

Kyle Cordes
www.kylecordes.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 14:06:01 UTC
Permalink
----- On Wednesday, September 25, 2002 5:03 PM, kentlbeck wrote:

> After listening a bit more, I read half of your article as
> saying, "I was in this extremely valuable situation. I did something
> other than what XP says. It worked. Therefore, this dog won't hunt."
>
> Another tack to take is to say, "I'm not sure how XP would apply to
> a one-month project sponsored by the CEO." You'd get a variety of
> responses, but they'd all be around the theme of shorter iterations
> (I'd choose 1 day) and continued business involvement (like the CEO
> steering once a week and a business representative at the morning
> stand-ups). I'd also inform the requirements discussion with
> estimates during the initial two days.

I've worked at both ends of the extreme; startups and Fortune 50. XP, as
currently constituted, would work just fine in the startups. It would not
work, however, in the Fortune 50 environments. Not without extension to
address the needs of the participants in that environment. The prototyping
effort was an example of what I think may be part of the solution to the
problem of addressing the needs of the management / customer constituency as
XP moves into the mainstream.

> The second half of the article (and your day 2 message) is about
> marketing XP, part of which hinges on the seemingly impossible
> requirement that business folks do their old job and act as members
> of the project team at the same time, part of which hinges on how to
> sell the shift of responsibility.
>
> Re: whole team. Projects go better with real, day-to-day business
> involvement. I say it. Standish says it (#1 on their list of
> correlations with project success is customer involvement). I don't
> think this is what we are debating. The question is whether business
> is willing to pay the price. We certainly haven't done a good job of
> communicating the benefits they can expect.
>
> Re: selling the shift of responsibility. It is a trade. The
> programmers offer transparency and control in return for business
> accepting responsibility for scope. I'm stumped by how to
> communicate this in an attractive way.
>
> Kent


I'm aware of what Standish says, and so is corporate management. Like you,
we're all trying to figure out how to address that problem. My position is
that XP, from the perspective of the "officially advocated practices," would
exacerbate that problem. Until recently, I too was stumped on the question
of how to fix the customer involvement problem. My experience with this new
generation of prototyping tool has shown me a glimmer of hope.

As far as accepting responsibility for scope, the businesses I've worked in
have always accepted that responsibility. I think what you mean is that XP
insists that they accept, up front, that they may not get everything they
need. I think that possibility is also something they already accept.
Their experience certainly supports it. But I think it's something they
hope will be remedied, rather than something they're just going to have to
get used to. I'm not sure how putting it "in their face" helps the
relationship, but I can see why programmers would want it. I'd much rather
figure out how to relieve pain than figure out how to live with it. And I
still have hope that we can figure out how to relieve it. That's what the
prototyping thing holds out for me. Maybe I'm just deluding myself. Time
will tell.

Best regards,
Bill



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 14:19:07 UTC
Permalink
On Thursday, September 26, 2002, at 10:06:01 AM, Bill Walton wrote:

> I'm aware of what Standish says, and so is corporate management. Like you,
> we're all trying to figure out how to address that problem. My position is
> that XP, from the perspective of the "officially advocated practices," would
> exacerbate that problem. Until recently, I too was stumped on the question
> of how to fix the customer involvement problem. My experience with this new
> generation of prototyping tool has shown me a glimmer of hope.

How would having the customer present with the project exacerbate the
problem? Standish says you need it, we say you need it. I don't
understand.

Ron Jeffries
www.XProgramming.com
Computers are useless. They can only give you answers. -- Picasso


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 18:33:55 UTC
Permalink
Hi Ron,

----- On Thursday, September 26, 2002 9:19 AM, Ron Jeffries wrote:

> > I'm aware of what Standish says, and so is corporate management. Like
you,
> > we're all trying to figure out how to address that problem. My position
is
> > that XP, from the perspective of the "officially advocated practices,"
would
> > exacerbate that problem. Until recently, I too was stumped on the
question
> > of how to fix the customer involvement problem. My experience with this
new
> > generation of prototyping tool has shown me a glimmer of hope.
>
> How would having the customer present with the project exacerbate the
> problem? Standish says you need it, we say you need it. I don't
> understand.

Sorry, I meant exacerbate the problem from the perspective of the customer
who's already participating in IT projects and doing their regular jobs.
Standish says they need to participate more. How do they do that and still
do their regular job except by working longer hours? XP says (as I
interpret it) they need to participate constantly. Longer hours. All while
one of XP's premises is that the programmers should be working at a
"sustainable pace." What do you find sustainable about the customer's
situation? The XP conversation seems to be primarily aimed at the active
participants. It seems to me that this is a conversation XP needs to take
up with that customer's management; a conversation about under what
circumstances an XP project should be undertaken.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 18:46:58 UTC
Permalink
On Thu, 2002-09-26 at 11:33, Bill Walton wrote:
> How do they do that and still
> do their regular job except by working longer hours? XP says (as I
> interpret it) they need to participate constantly. Longer hours. All while
> one of XP's premises is that the programmers should be working at a
> "sustainable pace." What do you find sustainable about the customer's
> situation?

A few of us have asked you what you've read about XP before coming here,
Bill; it seems you haven't had a chance to answer those questions yet.
Based on your statements, my impression is that you haven't read any of
the XP books.

Is that correct? If so, you might find it helpful to read Kent's book
and Ron's book. They cover a lot of your questions with more care and
thoughtfulness than most of us have the time to do in a newsgroup.


Thanks,

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 20:28:13 UTC
Permalink
Hi William,

----- On Thursday, September 26, 2002 1:46 PM, William Pietri wrote:

> A few of us have asked you what you've read about XP before coming here,
> Bill; it seems you haven't had a chance to answer those questions yet.
> Based on your statements, my impression is that you haven't read any of
> the XP books.
>
> Is that correct?

That is correct. I explained why in an email I just finished, but I'll do
so again. When I first heard about XP in 2000 I was a manager over a test
automation group. I was also still called on, in special problem cases, to
act as a project manager over the testing of large projects, particularly
ones that were already in trouble. I read about XP in the trade rags, heard
about it from programmer friends, checked out web sites, etc. It was clear
that XP didn't much value any of the roles I was engaged in. So I didn't
feel compelled to spend the time / money / energy to learn more. I did
recheck the status on what I perceived as the major web sites prior to
writing the column, and I joined this forum to observe whether anything
significant had changed. It did not appear that it had. I'm not sure it
has, at least "officially," although I do see that testers seem to be
finding a role within XP.

> If so, you might find it helpful to read Kent's book
> and Ron's book. They cover a lot of your questions with more care and
> thoughtfulness than most of us have the time to do in a newsgroup.

I may do that.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 19:31:01 UTC
Permalink
On Thursday, September 26, 2002, at 2:33:55 PM, Bill Walton wrote:

>> How would having the customer present with the project exacerbate the
>> problem? Standish says you need it, we say you need it. I don't
>> understand.

> Sorry, I meant exacerbate the problem from the perspective of the customer
> who's already participating in IT projects and doing their regular jobs.
> Standish says they need to participate more. How do they do that and still
> do their regular job except by working longer hours? XP says (as I
> interpret it) they need to participate constantly. Longer hours. All while
> one of XP's premises is that the programmers should be working at a
> "sustainable pace." What do you find sustainable about the customer's
> situation?

Um, I'm having trouble with this. The fact is that more involvement
means better project. There is no known /less involvement means better
project/ solution.

As for working at a sustainable pace, the premise is that the /team/
should work at a sustainable pace. The customer team members should
work at a sustainable pace. No one has said otherwise.

> The XP conversation seems to be primarily aimed at the active
> participants. It seems to me that this is a conversation XP needs to
> take up with that customer's management; a conversation about under
> what circumstances an XP project should be undertaken.

Whenever you're willing to do the process? When should a less
effective process be chosen? When is some other process actually
/more/ effective? I'd like to know. When some other process is more
effective, it should be chosen.

Ron Jeffries
www.XProgramming.com
Curiosity is more powerful than skepticism.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
kentlbeck
2002-09-26 16:46:49 UTC
Permalink
I read your development story as:
1. You needed two days of intense customer involvement for the
prototyping
2. For the rest of the month the requirements didn't change
3. The project was terrifically successful in the eyes of the CEO
who thought up the idea in the first place

If you let me fix requirements, the rest is easy. If you think
you've found a way to fix requirements and you're right, you win,
toss XP. It's not how I'm betting.

Standish says customer involvement is key, but they don't say
anything about *how* to involve the customer. XP says precisely how,
starting with physical relocation of the development staff to sit
with the "customers", and quarterly, weekly, and daily scope
negotiation for the duration of the project. If folks want the
benefits of customer involvement, but they don't want to do this,
fine. What's the alternative? Your example is one alternative, but
it only works if the requirements don't change.

The result is a process that gives successively refined answers to
the question, "What can I get for my money?" and guarantees that the
team will always be working on the most valuable tasks from the
perspective of that quarter, week, or day. That's seems to me to be
a valuable proposition compared with what they are getting for their
money today. I apologize that it requires changes on everyone's
part, but if we do the same kind of things, we can generally expect
the same kind of results, which pretty much implies that if we want
different results we have to do different things.

Once more, if you've cracked the problem of changing requirements by
your prototyping style, more power to you, game over.

Kent


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 19:15:31 UTC
Permalink
Hi Kent,

----- On Thursday, September 26, 2002 11:46 AM, Kent Beck wrote:

> If you let me fix requirements, the rest is easy. If you think
> you've found a way to fix requirements and you're right, you win,
> toss XP. It's not how I'm betting.

There are two problems with requirements. One stems from finding out that
requirements were missed or misunderstood. XP seems to address that quite
nicely, but introduces other challenges by way of its solution to the
problem. Specifically the overworked customer problem I talked about in the
column and here more than once. In some cases that will be workable, in
others, probably not. The other problem with requirements stems from
changes in the business that occur during the project. I suspect you'd say
that XP addresses this by having the customer involved throughout so that
these changes do not go unnoticed. I can see how that could be true in some
cases. I try to put it into my own experience and see how it would fit, and
I see projects, assuming the overworked customer problem was not an issue,
it would have worked and others where it might not have. Please remember
that I typically work on large projects spanning 6-9 months at a minimum and
involving multiple business groups. Not having hands-on XP experience but
understanding the "story" orientation, I suspect I would work with customer
groups serially. Under this scenerio, it seems to me there's a good
possibility that the business change could happen in a group we'd already
finished with and that the change might still go unnoticed. I don't know.
Maybe even the ones you're "finished with" still have to stay engaged. You
tell me. In any event, I reiterate that I'm having this discussion because
I *don't* want to see XP tossed. I'm sorry I still haven't overcome that
perception.

> Standish says customer involvement is key, but they don't say
> anything about *how* to involve the customer. XP says precisely how,
> starting with physical relocation of the development staff to sit
> with the "customers", and quarterly, weekly, and daily scope
> negotiation for the duration of the project. If folks want the
> benefits of customer involvement, but they don't want to do this,
> fine. What's the alternative? Your example is one alternative, but
> it only works if the requirements don't change.

Yep. And I'm not sure it works completely then. My question is "would it
help alievate the overworked customer problem?" and "would it work with XP?"

> The result is a process that gives successively refined answers to
> the question, "What can I get for my money?" and guarantees that the
> team will always be working on the most valuable tasks from the
> perspective of that quarter, week, or day. That's seems to me to be
> a valuable proposition compared with what they are getting for their
> money today.

That will work for some.

> I apologize that it requires changes on everyone's
> part, but if we do the same kind of things, we can generally expect
> the same kind of results, which pretty much implies that if we want
> different results we have to do different things.

Discontinuous vs. continuous change. Good discussion of this in Moore' s
book.

> Once more, if you've cracked the problem of changing requirements by
> your prototyping style, more power to you, game over.

Here's what I'm missing. How important *is* the iterative requirements
definition practice to XP? To me, the test-driven development, continuous
integration, single coding standard, and collective ownership practices are
much more important. But that's me looking in. How's it look from the
inside out? I'm serious. I want to know.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-25 22:23:37 UTC
Permalink
Howdy, Bill! Thanks for expressing your opinions to us! I certainly
agree that we techies should work as hard to understand the business
perspective as we want them to understand the technical perspective.

On Wed, 2002-09-25 at 14:11, Bill Walton wrote:
> At the same time, XP is advocating practices that, at least by
> existing, generally accepted business practices, would be seen as
> reducing that oversight capability. I'm talking specifically about
> the card-based planning and reporting you've schooled me on. Anything
> that diminishes the exec's ability to fulfill her oversight
> responsibility, or makes it harder or more time consuming, is likely
> to get shot before it gets through the door.

Could you tell us more about why you think this is so? I would agree
that XP by default produces less project paperwork. But I think that
makes oversight easier, not harder.

I've seen a numbers of specs that were well over 100 pages and that were
accompanied with extensive GANTT charts and MS Project plans. Some of
them started as works of fiction, but by no more than half-way through
the project, they were all woefully out of touch with reality.

So instead consider the XP stack of estimated cards. If at any point an
upper upper needs an executive summary, the customer should have no
problem taking the stack and writing up anything the exec needs. If the
exec wants to know the real scoop, he can come down from the mountain
and add up the points on the cards himself and look at the velocity
chart. And he can try out working software every week.

As Steve McConnell writes, "Many projects get to the point where they
are 90 percent complete and then stay at that point for months or even
years." The truth, of course, is that the projects aren't 90% complete;
the programmers just tell you that, either because they think it's true
or because it's the thing you want to hear. XP's Velocity only counts
stories that are provably 100% complete.


Thus, I'd say that XP drastically increases transparency compared with
traditional methods. That seems much better to me for oversight, for
accurate planning, for careful budgeting. What about it doesn't appeal
to you?


Thanks,

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-09-26 10:52:12 UTC
Permalink
--- In ***@y..., William Pietri <***@s...> wrote:
>
> I've seen a numbers of specs that were well over 100 pages and that were
> accompanied with extensive GANTT charts and MS Project plans. Some of
> them started as works of fiction, but by no more than half-way through
> the project, they were all woefully out of touch with reality.

Some years ago, I had a manager who told me that he wanted any reports either under six pages, or over six inches thick. Being naturally curious, I asked him why. His response was a classic that I have (rather obviously) remembered:

"If it's less than six pages, I'll read it. If it's more than six inches thick, I can use it as a doorstop. Anything in between is useless."

John Roth


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pierre Boudreau
2002-09-26 15:36:50 UTC
Permalink
> Some years ago, I had a manager who told me that he wanted any reports
either under six pages, or over six inches thick. Being naturally curious, I
asked him why. His response was a classic that I have (rather obviously)
remembered:
>
> "If it's less than six pages, I'll read it. If it's more than six inches
thick, I can use it as a doorstop. Anything in between is useless."

My current manager told me to keep it under 3 sentences :-)

Is she an eXtreme Manager?


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 18:05:18 UTC
Permalink
----- On Thursday, September 26, 2002 5:52 AM, John Roth wrote:

> Some years ago, I had a manager who told me that he wanted any reports
either under six pages, or over six inches thick. Being naturally curious, I
asked him why. His response was a classic that I have (rather obviously)
remembered:
>
> "If it's less than six pages, I'll read it. If it's more than six inches
thick, I can use it as a doorstop. Anything in between is useless."
>

That is a classic.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 14:23:38 UTC
Permalink
----- On Wednesday, September 25, 2002 5:23 PM, William Pietri wrote:

> On Wed, 2002-09-25 at 14:11, Bill Walton wrote:
> > At the same time, XP is advocating practices that, at least by
> > existing, generally accepted business practices, would be seen as
> > reducing that oversight capability. I'm talking specifically about
> > the card-based planning and reporting you've schooled me on. Anything
> > that diminishes the exec's ability to fulfill her oversight
> > responsibility, or makes it harder or more time consuming, is likely
> > to get shot before it gets through the door.
>
> Could you tell us more about why you think this is so? I would agree
> that XP by default produces less project paperwork. But I think that
> makes oversight easier, not harder.

I can see how it makes it easier at the immediate level, but still cannot in
terms of the management chain. I'm beginning to think this may be just a
function of the size of the companies I work in. A recent posting talks
about the CEO having steering meetings. In the companies I work in, there
are dozens if not hundreds of IT projects going on across the company at any
point in time. I have this picture in my mind of the exec's response to
hearing that she needs to meet with each team on a very regular basis and to
get status on projects, she'll be able to go look at the team's card stack
and see the working pieces of the application. That's not the way oversight
works at large companies.

> I've seen a numbers of specs that were well over 100 pages and that were
> accompanied with extensive GANTT charts and MS Project plans. Some of
> them started as works of fiction, but by no more than half-way through
> the project, they were all woefully out of touch with reality.

I've see this too, all too often. That's a project management issue. XP
doesn't "officially" recognize the need for project managers. I'm
suggesting that, as XP moves closer to the mainstream, it needs to.

> So instead consider the XP stack of estimated cards. If at any point an
> upper upper needs an executive summary, the customer should have no
> problem taking the stack and writing up anything the exec needs. If the
> exec wants to know the real scoop, he can come down from the mountain
> and add up the points on the cards himself and look at the velocity
> chart. And he can try out working software every week.

The management chain needs a summary on a regular basis. That's one of the
reasons we have project managers. As far as the exec "coming down from the
mountain, etc.", I addressed that in my first comment.

> As Steve McConnell writes, "Many projects get to the point where they
> are 90 percent complete and then stay at that point for months or even
> years." The truth, of course, is that the projects aren't 90% complete;
> the programmers just tell you that, either because they think it's true
> or because it's the thing you want to hear. XP's Velocity only counts
> stories that are provably 100% complete.
> >
> Thus, I'd say that XP drastically increases transparency compared with
> traditional methods. That seems much better to me for oversight, for
> accurate planning, for careful budgeting. What about it doesn't appeal
> to you?

It does appeal to me, at the lowest levels of the small project. Now, take
this and figure out how it fits into the role of the project manager and the
communications that role is charged with providing to the management chain,
make it part of the "official doctrine" for projects in a specific context
(i.e., large projects), and you've got a horse race.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 18:04:44 UTC
Permalink
On Thu, 2002-09-26 at 07:23, Bill Walton wrote:
>
> > Thus, I'd say that XP drastically increases transparency compared with
> > traditional methods. That seems much better to me for oversight, for
> > accurate planning, for careful budgeting. What about it doesn't appeal
> > to you?
>
> It does appeal to me, at the lowest levels of the small project. Now, take
> this and figure out how it fits into the role of the project manager and the
> communications that role is charged with providing to the management chain,
> make it part of the "official doctrine" for projects in a specific context
> (i.e., large projects), and you've got a horse race.

It depends on what you mean by the term "project manager." Different
organizations seem to mean everything from "project accountant" to
"project secretary" to "technical lead" to "product manager".

If you're referring to the keep-track-of-things activities, then I would
expect that any competent PM who attended the release and iteration plan
meetings and occasionally visited the team could take the current stack
of cards and the velocity history and write the needed reports. By
sitting in the room while writing the reports, they could pepper the
team with any questions that might come up. Do you think that would
work?

If instead the PM was involved in the deciding-what-to-build activities,
then I would have them be either the Customer or part of the group of
people that takes on the role of Customer. Then they would have an even
easier time of writing the reports.


In other communities, I have seen people take XP's relative silence on
what the Customer should do to mean that XP says, "Customers shouldn't
do anything outside of this book," rather than, "Although the inputs
tohe development process are the same, the particulars of the Customer
role vary widely depending on industry, company size, and organizational
culture, so XP should be looked at as a piece of a puzzle rather than a
silver bullet."

Or more succinctly: XP only answers the question, "How should we build
software?" rather than, "What software should we build?" or "How should
we fit building software into our company?"

Could that be the source of some of your concerns about XP? If so, I
encourage you to look at XP as an opportunity to answer those other
questions yourself, rather than demanding that it have ready-made
answers that might not fit your situation.


William


--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 19:06:22 UTC
Permalink
Hi William,

> Or more succinctly: XP only answers the question, "How should we build
> software?" rather than, "What software should we build?" or "How should
> we fit building software into our company?"
>
> Could that be the source of some of your concerns about XP? If so, I
> encourage you to look at XP as an opportunity to answer those other
> questions yourself, rather than demanding that it have ready-made
> answers that might not fit your situation.

I think it's reasonable to ask how other people have answered those
questions, and how those answers have played in various contexts.
It's clear to me that Bill isn't likely to treat our answers as
ready-made for all situations.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 19:23:22 UTC
Permalink
On Thu, 2002-09-26 at 12:06, Dale Emery wrote:
>
> > Or more succinctly: XP only answers the question, "How should we build
> > software?" rather than, "What software should we build?" or "How should
> > we fit building software into our company?"
> >
> > Could that be the source of some of your concerns about XP? If so, I
> > encourage you to look at XP as an opportunity to answer those other
> > questions yourself, rather than demanding that it have ready-made
> > answers that might not fit your situation.
>
> I think it's reasonable to ask how other people have answered those
> questions, and how those answers have played in various contexts.
> It's clear to me that Bill isn't likely to treat our answers as
> ready-made for all situations.

Indeed! I'm sorry if I gave a different impression. I think those
questions are excellent to ask. As Kent just said, there are many good
books to be written about them, and it would be swell if Bill wrote one.

I made this point only because Bill's original article gave me the
impression he wasn't so much asking them as whomping us with a stick
because we hadn't given him answers tuned for the Fortune 50 environment
in the (as yet unnamed) sources from which he learned about XP.

Once he asks those questions, I'm sure we can give him many helpful
tips.

William


--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Charlie Poole
2002-09-26 19:11:53 UTC
Permalink
Bill,

> > Thus, I'd say that XP drastically increases transparency compared with
> > traditional methods. That seems much better to me for oversight, for
> > accurate planning, for careful budgeting. What about it doesn't appeal
> > to you?
>
> It does appeal to me, at the lowest levels of the small project. Now,
take
> this and figure out how it fits into the role of the project manager and
the
> communications that role is charged with providing to the management
chain,
> make it part of the "official doctrine" for projects in a specific context
> (i.e., large projects), and you've got a horse race.

Ah ha! Some common ground at last. :-)

We've had a lot of discussion around here about whether XP should "expand"
to cover things that are needed in certain contexts, or whether it's better
for it to remain focused on what it already does well. I'm one who has
argued for the latter course.

I think one of XP's strengths is that it does not try to be all things for
all people. There could be a whole addendum to XP that talked about how the
Customer role is carried out, how to resolve conflicting priorities within
the organization, how to manage multiple (or even one) project. There isn't
and I don't think there needs to be. There are already large bodies of
knowledge available to those who need it about how to do those things,
and XP's efforts are, in my opinion, better directed toward improving the
things it knows how to improve.

Of course not all approaches to solving these other problems will be
consistent with XP, so a company will need to create a process that
empowers small teams working on projects in an XP vein. In fact, there
are several approaches to management which have explicitly encapsulated
XP in this way, most notably Scrum.

There is a great power in abstracting away from things that are not
directly important to what is going on in a small team. In XP, the
role of the Customer - however it is filled - allows developers to
work without the slightest doubt about whether they are working on
the right thing at the right time. Of course it could be argued that
this only begs the question - on first sight that was my reaction.
But viewing this as an abstraction or encapsulation, rather than a
gap in XP changes things entirely. So long as the Customer role is
working well, I can ignore it. When it stops working, I can draw on
my experience to help it work better. Depending on what went wrong,
my solution may have nothing whatsoever to do with XP, but will
instead draw on other areas of experience. I find no practical
problem with that in my work.

As a practitioner working in medium-size companies, I come across
very similar problems to what you describe. I've succeeded in
"training" various clients to not care quite so much about the
details of what goes on in projects and to look only at results.
I credit the simplified world-view that XP provides with my being
able to do this. Managers with whom I work are not naive. They
know that any process or methodology is a simplification of the
real world. They want a simplification that will work for them
and XP can be a large part of the solution without much tweaking.

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 19:44:14 UTC
Permalink
Hi William,

----- On Thursday, September 26, 2002 1:04 PM, William Pietrif wrote:

> On Thu, 2002-09-26 at 07:23, Bill Walton wrote:
> >
> > > Thus, I'd say that XP drastically increases transparency compared with
> > > traditional methods. That seems much better to me for oversight, for
> > > accurate planning, for careful budgeting. What about it doesn't appeal
> > > to you?
> >
> > It does appeal to me, at the lowest levels of the small project. Now,
take
> > this and figure out how it fits into the role of the project manager and
the
> > communications that role is charged with providing to the management
chain,
> > make it part of the "official doctrine" for projects in a specific
context
> > (i.e., large projects), and you've got a horse race.
>
> It depends on what you mean by the term "project manager." Different
> organizations seem to mean everything from "project accountant" to
> "project secretary" to "technical lead" to "product manager".
>
> If you're referring to the keep-track-of-things activities, then I would
> expect that any competent PM who attended the release and iteration plan
> meetings and occasionally visited the team could take the current stack
> of cards and the velocity history and write the needed reports. By
> sitting in the room while writing the reports, they could pepper the
> team with any questions that might come up. Do you think that would
> work?

Yep.

> If instead the PM was involved in the deciding-what-to-build activities,
> then I would have them be either the Customer or part of the group of
> people that takes on the role of Customer. Then they would have an even
> easier time of writing the reports.

Yep. That would be even better.

> In other communities, I have seen people take XP's relative silence on
> what the Customer should do to mean that XP says, "Customers shouldn't
> do anything outside of this book," rather than, "Although the inputs
> tohe development process are the same, the particulars of the Customer
> role vary widely depending on industry, company size, and organizational
> culture, so XP should be looked at as a piece of a puzzle rather than a
> silver bullet."

Aha! Now take "XP's relative silence in what the Customer should do" and
the problem you talked about, and extrapolate the problems that are likely
to result by XP's even greater silence on the roles of project managers,
managers, etc.

> Or more succinctly: XP only answers the question, "How should we build
> software?" rather than, "What software should we build?" or "How should
> we fit building software into our company?"

These would be good things to add to the "here there be dragons" list.

> Could that be the source of some of your concerns about XP? If so, I
> encourage you to look at XP as an opportunity to answer those other
> questions yourself, rather than demanding that it have ready-made
> answers that might not fit your situation.

Yes, those cover most, if not all (I'd have to do an inventory and I'm
trying to get through the backed-up emails so I won't take the time right
now), of the concerns I have right now. As far as answering them for
myself, I have to say my interest level is higher than it was, so I might
take that on. But, to reiterate, the mainstream customers XP is trying to
sell, if indeed that's the case, won't.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 20:08:37 UTC
Permalink
On Thu, 2002-09-26 at 12:44, Bill Walton wrote:
>
> > [...] XP should be looked at as a piece of a puzzle rather than a
> > silver bullet."
>
> Aha! Now take "XP's relative silence in what the Customer should do" and
> the problem you talked about, and extrapolate the problems that are likely
> to result by XP's even greater silence on the roles of project managers,
> managers, etc.

Oh, I've done some of that already. It's fun! And solving the problems
is even more fun. In fact, it's part what I do for a living. The same
goes for a lot of people on this group.


> > Could that be the source of some of your concerns about XP? If so, I
> > encourage you to look at XP as an opportunity to answer those other
> > questions yourself, rather than demanding that it have ready-made
> > answers that might not fit your situation.
>
> Yes, those cover most, if not all (I'd have to do an inventory and I'm
> trying to get through the backed-up emails so I won't take the time right
> now), of the concerns I have right now. As far as answering them for
> myself, I have to say my interest level is higher than it was, so I might
> take that on. But, to reiterate, the mainstream customers XP is trying to
> sell, if indeed that's the case, won't.

Oh, I'd agree! If XP were a thing that could sell, and if it were trying
to sell to the mainstream, it should do those things. But since it's not
a person or a company, I don't think that it should.

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 20:24:45 UTC
Permalink
Hi William,

> Oh, I'd agree! If XP were a thing that could sell, and if it were
> trying to sell to the mainstream, it should do those things. But since
> it's not a person or a company, I don't think that it should.

I'm taking "sell" to mean something broader than just a selling
product or service to a customer for money. I see messages here
frequently from people wondering "how do I convince my
manager/colleagues to do/try/acknowledge XP." That seems like selling
to me. And I'm guessing that those managers and colleagues often fit
into the category "mainstream."

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 20:44:12 UTC
Permalink
On Thu, 2002-09-26 at 13:24, Dale Emery wrote:
> > Oh, I'd agree! If XP were a thing that could sell, and if it were
> > trying to sell to the mainstream, it should do those things. But since
> > it's not a person or a company, I don't think that it should.
>
> I'm taking "sell" to mean something broader than just a selling
> product or service to a customer for money. I see messages here
> frequently from people wondering "how do I convince my
> manager/colleagues to do/try/acknowledge XP." That seems like selling
> to me. And I'm guessing that those managers and colleagues often fit
> into the category "mainstream."

I agree completely. I meant to imply that XP is just a process, a tool,
a way of doing things. Like a rock or a tree, XP can't sell itself; it
just goes on being what it is.

But the people and companies who want XP to be adopted should certainly
sell XP, each in their own way. And I certainly agree that they should
talk together and swap tips on the best way to do that in particular
market segments.

I just meant to imply that Bill is treating XP as a product company that
should cater to his particular needs. I think those expectations are
misplaced. He should certainly have those expectations with respect to,
say, Object Mentor or Rational, and I'm sure that Lowell and Gary are
utterly happy to fill those expectations.

Sorry my attempt to be pithy caused confusion!


William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Laurent Bossavit
2002-09-25 22:51:46 UTC
Permalink
Bill:

> The world we work in today is dominated by intense scrutiny and
> legislation regarding the effectiveness of the CEO / CFO in their
> fiduciary oversight role.

Now *that* stopped me in my tracks. I don't think I work in that
world. I work in the world where they let Jean-Marie Messier away
with murder, and France Telecom piss away 70 billion eurodollars.

At a smaller level, I work in a world where *my* boss ran his company
into the ground, leaving 30+ employees in quite difficult financial
situations, but he had already all but retired from the day-to-day
running of the company a couple, three months before bankruptcy
protection proceedings were over and done with. Near the end of that
these 30+ employees were all "acquired" like so much cattle by a
different company. Quite possibly to repeat the same cycle again.

> At the very least, I think the XP leadership needs to publish
> prominently, where execs would know about it and have ready access to
> it, a short list (not a book) of "here there be dragons."

Why not a book ?

Cheers,

-[Morendil]-
We are like sailors who have to rebuild their ship on the open sea,
without ever being able to dismantle it in dry-dock and reconstruct
it from the best components.
Otto Neurath



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 01:49:54 UTC
Permalink
From: "Laurent Bossavit" <***@bossavit.com>

> > The world we work in today is dominated by intense scrutiny and
> > legislation regarding the effectiveness of the CEO / CFO in their
> > fiduciary oversight role.

> Now *that* stopped me in my tracks. I don't think I work in that


It is also a *fantastic* way to torpedo an idea... find a way to
insinuate that the idea could be not merely a bad idea but a breach of
fiduciary duty and legally perilous.

What if I were to say that using a whiz-bang prototype tool to quite
possibly produce totally incorrect expectations on the part of a
customer, is a dangerous thing to do in an environment with great
scrutity on CEO/CFO fiduciary oversight? That doing so might set things
up to have a date slip on crucial product, make the firm miss revenue
targets, trigger shareholder lawsuits, get the CFO indicted, etc.?
Would that be a good argument?

(No, it would not. Let's talk about the merits of ideas, not use the
"post-Enron" business environment to spread FUD.)

Kyle Cordes
www.kylecordes.com



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 16:23:44 UTC
Permalink
----- On Wednesday, September 25, 2002 8:49 PM, Kyle Cordes wrote:


> From: "Laurent Bossavit" <***@bossavit.com>
>
> > > The world we work in today is dominated by intense scrutiny and
> > > legislation regarding the effectiveness of the CEO / CFO in their
> > > fiduciary oversight role.
>
> > Now *that* stopped me in my tracks. I don't think I work in that
>
>
> It is also a *fantastic* way to torpedo an idea... find a way to
> insinuate that the idea could be not merely a bad idea but a breach of
> fiduciary duty and legally perilous.
>
> What if I were to say that using a whiz-bang prototype tool to quite
> possibly produce totally incorrect expectations on the part of a
> customer, is a dangerous thing to do in an environment with great
> scrutity on CEO/CFO fiduciary oversight? That doing so might set things
> up to have a date slip on crucial product, make the firm miss revenue
> targets, trigger shareholder lawsuits, get the CFO indicted, etc.?
> Would that be a good argument?
>
> (No, it would not. Let's talk about the merits of ideas, not use the
> "post-Enron" business environment to spread FUD.)

Excellent insight, Kyle. Now let's examine that a little further. Please
forgive me for using your own words against your position, but try this one
on for size.

What if I were to say that [XP] is a dangerous thing to do in an environment
with great scrutity on CEO/CFO fiduciary oversight? That doing so might set
things up to have a date slip on crucial product, make the firm miss revenue
targets, trigger shareholder lawsuits, get the CFO indicted, etc.? Would
that be a good argument?

No it would not. But it could certainly be an effective one. Who might
advance such an argument? Probably any one that felt threatened by XP and
what it would mean to them. Who's that? Managers of test groups. Managers
of project management groups. Managers who have either of those functions
within their groups. Managers of business units whose people are already
feeling overworked by doing double duty due to their involvement in IT
projects. Anybody who's supported the development of an independent test
function. Anyone who's supported the development of a project management
discipline / function. In short, any one who XP leaves out or whose role is
substantially changed by XP.

How will XP address their concerns?

Best regards,
Bill



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 18:08:54 UTC
Permalink
On Thu, 2002-09-26 at 09:23, Bill Walton wrote:
>
> No it would not. But it could certainly be an effective one. Who might
> advance such an argument? Probably any one that felt threatened by XP and
> what it would mean to them. Who's that? Managers of test groups. Managers
> of project management groups. Managers who have either of those functions
> within their groups. Managers of business units whose people are already
> feeling overworked by doing double duty due to their involvement in IT
> projects. Anybody who's supported the development of an independent test
> function. Anyone who's supported the development of a project management
> discipline / function. In short, any one who XP leaves out or whose role is
> substantially changed by XP.
>
> How will XP address their concerns?
>

A good question. Those concerns should be addressed, of course. But
should they be addressed by XP? Or should those questions instead be
answered by the people adopting XP?

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 19:10:14 UTC
Permalink
Hi William,

> > How will XP address their concerns?
>
> A good question. Those concerns should be addressed, of course. But
> should they be addressed by XP? Or should those questions instead be
> answered by the people adopting XP?

Perhaps it would be easier and more useful to find answers to a few
question slightly different from the one Bill asked: How have XP
practitioners addressed those concerns? What have XP practitioners
tried that did not address those concerns?

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 19:46:15 UTC
Permalink
----- On Thursday, September 26, 2002 1:08 PM, William Pietri wrote:

> On Thu, 2002-09-26 at 09:23, Bill Walton wrote:
> >
> > No it would not. But it could certainly be an effective one. Who might
> > advance such an argument? Probably any one that felt threatened by XP
and
> > what it would mean to them. Who's that? Managers of test groups.
Managers
> > of project management groups. Managers who have either of those
functions
> > within their groups. Managers of business units whose people are
already
> > feeling overworked by doing double duty due to their involvement in IT
> > projects. Anybody who's supported the development of an independent
test
> > function. Anyone who's supported the development of a project
management
> > discipline / function. In short, any one who XP leaves out or whose
role is
> > substantially changed by XP.
> >
> > How will XP address their concerns?
> >
>
> A good question. Those concerns should be addressed, of course. But
> should they be addressed by XP? Or should those questions instead be
> answered by the people adopting XP?
>
> William
>

XP is in the role of the seller, trying to supplant an existing solution
(albeit one that doesn't work very well) so the burden is on XP.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 19:58:08 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> > A good question. Those concerns should be addressed, of course. But
> > should they be addressed by XP? Or should those questions instead be
> > answered by the people adopting XP?

> XP is in the role of the seller, trying to supplant an existing
solution
> (albeit one that doesn't work very well) so the burden is on XP.


Actually, XP is not really in the role of a seller. Unlike some other
popular methodologies, it's not a product to purchase. You can just
start doing it, and lots of people will tell you how for free, or for
the miniscule cost of a few books. If you want to hire someone
experienced to coach or train your team, you can - all the way up to
hiring some of the people who came up with it in the first place. Or
you can hire other people who have no financial connection to those
folks.

Kyle Cordes
www.kylecordes.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 19:01:28 UTC
Permalink
On Thursday, September 26, 2002, at 12:23:44 PM, Bill Walton wrote:

> What if I were to say that [XP] is a dangerous thing to do in an environment
> with great scrutity on CEO/CFO fiduciary oversight? That doing so might set
> things up to have a date slip on crucial product, make the firm miss revenue
> targets, trigger shareholder lawsuits, get the CFO indicted, etc.? Would
> that be a good argument?

> No it would not. But it could certainly be an effective one. Who might
> advance such an argument? Probably any one that felt threatened by XP and
> what it would mean to them. Who's that? Managers of test groups. Managers
> of project management groups. Managers who have either of those functions
> within their groups. Managers of business units whose people are already
> feeling overworked by doing double duty due to their involvement in IT
> projects. Anybody who's supported the development of an independent test
> function. Anyone who's supported the development of a project management
> discipline / function. In short, any one who XP leaves out or whose role is
> substantially changed by XP.

> How will XP address their concerns?

It would make as much sense to argue that XP might cause programmers
to attack end users with axes.

XP teams ship running, tested software every two weeks. There is no
way for a team that is really doing XP to "miss a date". They could
possibly have fewer features than were imagined, but they cannot miss
a date.

XP teams ship the most valuable features in the earliest of their two
week shipments of running, tested software. They could possibly ship
less value than was imagined, but teams that are really doing XP
always ship the maximum /possible/ value of software by any given
date, based on the sole decision of the team's customer.

XP teams have a clear way of projecting what is going to happen, and
they can produce a new projection in about a day, any time that it is
needed. The projection grows in accuracy as time goes on. There is no
way that the stakeholders of an XP project can be blind-sided by its
performance.

There is no way that I know of or can imagine to out-perform these
results. Can you suggest one?

Ron Jeffries
www.XProgramming.com
Yesterday's code should be as good as we could make it yesterday.
The fact that we know more today, and are more capable today,
is good news about today, not bad news about yesterday.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 20:58:38 UTC
Permalink
I think we're on two different planes here, Ron. You're back to arguing the
technical merits of the XP way. I'm saying that there are folks out there
that XP threatens. I can't respond effectively to your question.

Best regards,
Bill

----- Original Message -----
From: "Ron Jeffries" <***@acm.org>
To: <***@yahoogroups.com>
Sent: Thursday, September 26, 2002 2:01 PM
Subject: Re: [XP] fiduciary oversight


> On Thursday, September 26, 2002, at 12:23:44 PM, Bill Walton wrote:
>
> > What if I were to say that [XP] is a dangerous thing to do in an
environment
> > with great scrutity on CEO/CFO fiduciary oversight? That doing so might
set
> > things up to have a date slip on crucial product, make the firm miss
revenue
> > targets, trigger shareholder lawsuits, get the CFO indicted, etc.? Would
> > that be a good argument?
>
> > No it would not. But it could certainly be an effective one. Who might
> > advance such an argument? Probably any one that felt threatened by XP
and
> > what it would mean to them. Who's that? Managers of test groups.
Managers
> > of project management groups. Managers who have either of those
functions
> > within their groups. Managers of business units whose people are
already
> > feeling overworked by doing double duty due to their involvement in IT
> > projects. Anybody who's supported the development of an independent
test
> > function. Anyone who's supported the development of a project
management
> > discipline / function. In short, any one who XP leaves out or whose
role is
> > substantially changed by XP.
>
> > How will XP address their concerns?
>
> It would make as much sense to argue that XP might cause programmers
> to attack end users with axes.
>
> XP teams ship running, tested software every two weeks. There is no
> way for a team that is really doing XP to "miss a date". They could
> possibly have fewer features than were imagined, but they cannot miss
> a date.
>
> XP teams ship the most valuable features in the earliest of their two
> week shipments of running, tested software. They could possibly ship
> less value than was imagined, but teams that are really doing XP
> always ship the maximum /possible/ value of software by any given
> date, based on the sole decision of the team's customer.
>
> XP teams have a clear way of projecting what is going to happen, and
> they can produce a new projection in about a day, any time that it is
> needed. The projection grows in accuracy as time goes on. There is no
> way that the stakeholders of an XP project can be blind-sided by its
> performance.
>
> There is no way that I know of or can imagine to out-perform these
> results. Can you suggest one?
>
> Ron Jeffries
> www.XProgramming.com
> Yesterday's code should be as good as we could make it yesterday.
> The fact that we know more today, and are more capable today,
> is good news about today, not bad news about yesterday.
>
>
> To Post a message, send it to: ***@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 19:43:35 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> > What if I were to say that using a whiz-bang prototype tool to quite
> > possibly produce totally incorrect expectations on the part of a
> > customer, is a dangerous thing to do in an environment with great

> Excellent insight, Kyle. Now let's examine that a little further.
Please
> forgive me for using your own words against your position, but try
this one
> on for size.

> What if I were to say that [XP] is a dangerous thing to do in an
environment
> with great scrutity on CEO/CFO fiduciary oversight? That doing so
might set

You already said essentially that, in a previous message. Essentially I
repeated what you said, substituting "prototyping" for "XP". Now you
have repeated it back, resubstituting "XP" for "prototyping". This was
the thing which I believe is basically a name-calling attack. I don't
believe the XP or any other process I have heard of is dangerous in this
way. I don't think this is a helpful way to communicate.


> advance such an argument? Probably any one that felt threatened by XP
and
> what it would mean to them. Who's that? Managers of test groups.
Managers
> of project management groups. Managers who have either of those
functions
> within their groups. Managers of business units whose people are
already

This is a valid concern that people have. XP defines a small number of
roles, certainly there are people in organizations whose role is not
defined by XP. They might feel threatened, thinking "uhoh, what if it's
possible to make great software without needing me???" This is not a
weakness of XP, any more than the concerns that buggy-whip manufacturers
had about automobiles were a weakness of the automobile.

> How will XP address their concerns?

It probably won't. I don't think it's within the scope of XP to be, to
make sure a role is defined for every person in every organization. XP
is more about finding a minimum number of roles, practices, etc. to get
the job done, not finding a maximum. For various good reasons, many
organizations will add more roles, practices, etc. to those defined by
XP.

If you are looking for something that defines a great many possible
roles, artifacts, processes, etc., and can be configured to include
whichever of them you want to have, there is an excellent system for
doing that, at www.rational.com.

Kyle Cordes
www.kylecordes.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 20:16:45 UTC
Permalink
On Thu, 2002-09-26 at 12:43, Kyle Cordes wrote:
> > How will XP address their concerns?
>
> It probably won't. I don't think it's within the scope of XP to be, to
> make sure a role is defined for every person in every organization.

Very true! But I hasten to add:

I have never seen a project where an XP transition would require the
firing of people who are currently useful, productive, and able to work
in a team.

There may be no formal QA role, but if a project had good QA people, I'd
fight like a wild cat to keep them during an XP transition; they have an
orientation and an immense amount of knowledge that is very valuable.
Ditto for a middle manager, PM, BA, or almost any other role.

XP's lack of a formal transition plan for these people is not meant to
imply that we take 'em out behind the woodshed and shoot 'em.

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-09-26 10:55:45 UTC
Permalink
--- In ***@y..., "Laurent Bossavit" <***@b...> wrote:
> Bill:
>
> > The world we work in today is dominated by intense scrutiny and
> > legislation regarding the effectiveness of the CEO / CFO in their
> > fiduciary oversight role.
>
> Now *that* stopped me in my tracks. I don't think I work in that
> world. I work in the world where they let Jean-Marie Messier away
> with murder, and France Telecom piss away 70 billion eurodollars.
>
> At a smaller level, I work in a world where *my* boss ran his company
> into the ground, leaving 30+ employees in quite difficult financial
> situations, but he had already all but retired from the day-to-day
> running of the company a couple, three months before bankruptcy
> protection proceedings were over and done with. Near the end of that
> these 30+ employees were all "acquired" like so much cattle by a
> different company. Quite possibly to repeat the same cycle again.

I quite agree with you. All the executives are looking over their shoulders at things they can be hauled up before the judge for. So far, I haven't ever heard of anyone being hauled in on criminal charges for using the wrong systems development methodology - unless it was for fraud on a contract that explicitly stated what methodology was to be used.

> > At the very least, I think the XP leadership needs to publish
> > prominently, where execs would know about it and have ready access to
> > it, a short list (not a book) of "here there be dragons."
>
> Why not a book ?

The people who need to read it, won't.

John Roth
>
> Cheers,
>
> -[Morendil]-
> We are like sailors who have to rebuild their ship on the open sea,
> without ever being able to dismantle it in dry-dock and reconstruct
> it from the best components.
> Otto Neurath


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 14:31:07 UTC
Permalink
----- On Wednesday, September 25, 2002 5:51 PM, Laurent Bossavit wrote:

> Bill:
>
> > The world we work in today is dominated by intense scrutiny and
> > legislation regarding the effectiveness of the CEO / CFO in their
> > fiduciary oversight role.
>
> Now *that* stopped me in my tracks. I don't think I work in that
> world. I work in the world where they let Jean-Marie Messier away
> with murder, and France Telecom piss away 70 billion eurodollars.

Oops. It's easy to forget about reach. I can only address the U.S.
environment, where Enron, Anderson, WorldCom, and Tyco dominate the news.
Where the S.E.C. is investigating the retirement package of Jack Welch, one
of the icons of the American management scene; someone who, to my knowledge,
has never had a smudge on his record. Context is everything.


> > At the very least, I think the XP leadership needs to publish
> > prominently, where execs would know about it and have ready access to
> > it, a short list (not a book) of "here there be dragons."
>
> Why not a book ?

A book would be fine, but the exec shouldn't have to read the book to get a
high level understanding. That should come across clearly in the list
which, if it's valuable, will cause execs to want to spend the time to learn
more.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
banshee858
2002-09-26 16:08:26 UTC
Permalink
> > Why not a book ?
>
> A book would be fine, but the exec shouldn't have to read the book
to get a
> high level understanding. That should come across clearly in the
list
> which, if it's valuable, will cause execs to want to spend the time
to learn
> more.

These lazy suits can get up and read a book from time-to-time! None
of Kent's books (white or green) take that long to read. In fact,
they can read it while they travel in first class. What irks me
about these mythical CEO's is that while they make 10-25 times my
salary, we cannot even expect them to read a book in order to
understand a key process in their business! Talk about failing in
their oversight role. But what can you expect from people educated
in business?

Finally, if a CEO in a large company is directly involved with
steering of an XP project, that is big mistake. It is my opinion
that the CEO's do NOT need to run an XP project. I worked at Exxon
Exploration Company for a year and if Harry Long (CEO when I worked
there) was involved with the day-to-day activites of the Niger
project I worked on, I would be seriously worried about Exxon's
health. Thankfully, we had a manager who handled the day-to-day and
another manager above him who managed multiple projects in Chad and
Niger who then reported to a VP of Africa, who then reported to the
President of Exxon who then reported to the CEO Harry Long.

This oversight issue and reporting thread is a red herring people.
Even in large corporations (Exxon is THE largest energy company in
the world) many decisions are made without the oversight poor Bill
imagines to exist. The president or CEO of Exxon never cared if I
analyzed geologic strucutres by hand using paper on the computer.
All they wanted was a result and software, from I have seen, is much
the same.

I've also worked in a small start-up where the CEO was TOO involved
and that is bad as well. The CEO was so involved with everyone's
business he was reformatting the margins to the user manauls!
Unfortuantely, in that case our "trained" project manager did not act
as a shield from the well-intentioned, but interferring, actions of
the CEO. But hey, it was his company and if he wanted to be involved
in that level of detail, it was his right.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 18:21:28 UTC
Permalink
On Thu, 2002-09-26 at 09:08, banshee858 wrote:
>
> These lazy suits can get up and read a book from time-to-time! None
> of Kent's books (white or green) take that long to read.

Although I've had this feeling myself, I should point out that different
people learn differently.

We geeks are on the high end of the curve when it comes to things like
reading speed and reading skills. To many managers, "Just read this
short 300 page book," sounds like as much fun as, "Can you speak in
front of an audience of 100 this afternoon?" or "Joe and Steve are mad
at one another. Could you get them to make up and get back to work?"
would to your typical geek.

So if a manager will learn best from a 3-page summary or a 30-minute
presentation or a dramatic skit, I'm generally glad to do what I can for
them. I'll certainly recommend formats that I think will best convey the
information, but if the manager learns best through tap-danced morse
code, I'm willing to go get tap shoes.

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
banshee858
2002-09-26 18:59:07 UTC
Permalink
> Although I've had this feeling myself, I should point out that
different
> people learn differently.
>
> So if a manager will learn best from a 3-page summary or a 30-minute
> presentation or a dramatic skit, I'm generally glad to do what I
can for
> them. I'll certainly recommend formats that I think will best
convey the
> information, but if the manager learns best through tap-danced morse
> code, I'm willing to go get tap shoes.
>
Heard and understood. I generally prefer a covnersation or some type
of interactive presentation.

Still, if you don't take time to read the material, why should you be
given an A? Ugh!! The absolute unfairness of it all has always
grated me, but growing older has just taught me things are unfair and
nothing I do is going to change that.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 19:27:42 UTC
Permalink
On Thu, 2002-09-26 at 11:59, banshee858 wrote:
> The absolute unfairness of it all has always
> grated me, but growing older has just taught me things are unfair and
> nothing I do is going to change that.
>

I agree! We start bloody and screaming; we end up as worm food.
Unappealing and unfair. But I haven't yet found a better deal. And we
can certainly have some fun along the way!

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-09-25 23:51:27 UTC
Permalink
--- In ***@y..., "Bill Walton" <***@j...> wrote:

>
> My concerns are about the business side of XP, not the technical side. I have to assume that I wasn't very clear on this either in the StickMinds column or in my postings to this forum since the majority of your postings / responses yesterday were oriented at educating me on the technical aspects / merits of XP. I have noted that quite a few of the postings today have begun to address the business side of things. I'm hoping this posting may accelerate that. When I talk about the business side of things, what I mean to talk about is change. Change to what? How can we make that change happen? What are the chief obstacles to the change we seek? These are questions that require business answers, not technicals answer. You'll note that, from my perspective, the problem is about effective communication.
>
> --- Change to what? ---
> I assume that the intent of this group is to see XP become mainstream practice. If that's an incorrect assumption, someone please tell me because, in that case, I'm wasting your time and mine. If that's not an incorrect assumption, they we need to start thinking about this as a marketing problem. When I say marketing, I mean communication. An effective "elevator speech" is a recognized prerequisite to getting more of an executive's time to continue the discussion about the need for any change. That elevator speech must get the mainstream listener's attention by talking about the benefits of change without raising red-flags in their mind about increased risk. XP lacks this today.
>
> --- How can we make that change happen? ---
> The most important rule of leading change, in my experience, is to make sure all the parties know and agree about all the relevant aspects of where things stand today. Without that agreement, there can never be agreement about what the first step should be or whether it's a step forward or not. XP addresses where things stand from the programmer's perspective very eloquently. But I've yet to see anything but a programmer's view of things.

> Back to management for a sec. We all know the waterfall / V model does not produce good results from a technical perspective. When I say all, I mean executives too. At least the ones I know, know. So my question is "what is it about that model that continues to provide value to the exec that the XP model lacks?" If there wasn't something "good" about it, they'd have dropped it long ago. It's no good to speculate. We need real data. Once we have it, we may not like the answer. I suspect they do not like it either. But until we ask the question and understand that answer, I can't forsee them accepting a change to XP on any scale.

Actually, there's a very simple answer. To paraphrase Winston Churchill: Waterfall is the worst development methodology in existance - except for all the others. Or so it looks. Most large shops have been badly burned by the development fad dujour for a long, long time. And there is a lot of inertial from middle management.

> --- What are the primary obstacles to the change we seek? ---
> The world we work in today is dominated by intense scrutiny and legislation regarding the effectiveness of the CEO / CFO in their fiduciary oversight role. I can't imagine a CEO or CFO in any publicly-traded company today that isn't carefully examining every detail of how her company is being run for the possibility that it will get them into trouble (i.e., land them in jail). At the same time, XP is advocating practices that, at least by existing, generally accepted business practices, would be seen as reducing that oversight capability. I'm talking specifically about the card-based planning and reporting you've schooled me on. Anything that diminishes the exec's ability to fulfill her oversight responsibility, or makes it harder or more time consuming, is likely to get shot before it gets through the door.

The sales point here is that it actually *increases* the executive's ability to oversee the project in a meaningful manner. I agree with you that this point doesn't seem to be getting across.

> XP's current overall argument, as I understand it after you've explained many of the details, still seems almost calculated to offend and alienate the entire management chain by making them, at best, ask for entrance and prove that they will provide value to the process above and beyond what programmers can do "on their own." It lacks an element of respect for our co-workers. While I don't remember addressing them specifically in our exchanges, let's take a sec to talk about project managers. They have a pretty widely recognized and valued role in the mainstream. XP takes the position that they're optional. XP seems to say to the project manager, we programmers can provide all the value you do with less overhead. And with no need for the training, etc. you've been through or for your experience. By virtue of that, it says to those managers, directors, VP's, etc. who have championed project management, project management certification, PMO's, etc. that they've wasted
the company's time and money. It may not be what XP means to say, but it's what's coming across.

When you change a process radically, there are always going to be people who's specific job assignments change. Ghandi made a very good point when he asked: "If you shut down all the prisons, who would be the most affected?" The answer, of course, is the jailers. They would be out of jobs.

You cannot change process radically without making changes. The people who have invested the most in the current situation have the most to lose, and will fight to the death to keep things the way they are. See Machiavelli for the appropriate quotes.

> In addition, the hype that's been generated around XP is yielding who-knows-what conversations between programmers who want to do XP and their management? At the very least, I think the XP leadership needs to publish prominently, where execs would know about it and have ready access to it, a short list (not a book) of "here there be dragons." You need to give them a comfort level that they'll have the information they need when confronted with an enthusiastic, apparently knowledgeable, but wrong-headed employee who is liable, by your own estimation, to use XP in a way that will not likely yield good results. In short, you need to let them know you're not their enemy.

In other words, an executive management overview posted on one of the major sites.

John Roth


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 01:52:09 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> advocating practices that, at least by existing, generally a
> ccepted business practices, would be seen as reducing
> that oversight capability. I'm talking specifically about the
> card-based planning and reporting you've schooled me on.
> Anything that diminishes the exec's ability to fulfill her
> oversight responsibility, or makes it harder or more time
> consuming, is likely to get shot before it gets through the door.

I just don't see it. As far a I can tell, XP increases managerial
visibility compared to other ways of developing software with which I am
familiar. I've seen this same objection several places, but I can't
imagine how it could possibly work out that way for a team that's
anywhere near XP. Perhaps it's the teams that simply stop producing any
documents, mutter something about XP, and then never even try any of the
practices, that produce this.

Kyle Cordes
www.kylecordes.com




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kyle Cordes
2002-09-26 01:53:04 UTC
Permalink
From: "Bill Walton" <***@jstats.com>

> I assume that the intent of this group is to see XP become
> mainstream practice. If that's an incorrect assumption,
> someone please tell me because, in that case, I'm wasting
> your time and mine. If that's not an incorrect assumption,


Perhaps, perhaps not. Right now, I believe that teams/firms that employ
an XP-flavored process enjoy a competitive advantage (for many kinds of
projects) over those who do not. I enjoy having a competitive
advantage. It would suit me best if just enough firms use XP / Agile
methods, that I could easily find one if I needed new employment; yet
not so many that the advantage disappears.

I really don't mind if *you* (in the generic sense) choose not to do
anything like XP; but if someone asks me how to develop software, or I
am deciding how to organize a team, the answer will be more or less
XP-ish depending on the situation.

Kyle Cordes
www.kylecordes.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Chris Morris
2002-09-26 04:22:38 UTC
Permalink
Points I took from the original article:

- XP lacks sound business practices.
- Insisting the customer be involved throughout development is unreasonable.
- XP wants to keep development in a less than mainstream state of
craftsmanship.
- XP's approach to planning by steering throughout dodges up-front planning
that the real world demainds.
- XP is adolescent and only wants management to leave it alone.
- XP won't commit to predicting the project and yet demands it be paid to
work anyway.
- XP should be about telling C-level how the project will progress
beforehand.
- New prototyping tools could be a better solution for predicting a project
beforehand.

(btw, I like the combination of points 2 and 5...)

The previous thread tackled some of these. Of those that were tackled, it
seems some are still open, IMO:

- You championed the prototype in your example, yet many of us couldn't see
any substantial difference between taking time prototype and taking time to
start an XP iteration. What do you think?
- You say we need to be able to predict a project's outcome to an exec
before starting, we said you can as long as it's understood that that plan
will most likely change. Does this satisfy your critique in the article or
not?

... not to mention all of the original points that haven't been discussed.

And now we get an entirely different summation post telling us that your
main concerns are now:

- XP doesn't have a good elevator sales pitch.
- XP needs data telling us what Waterfall / V has over XP.
- XP needs better internal documentation to allow CFOs to audit the work.
- XP is too dismissive to project management personnel and training.
- XP needs to document warning signs of an XP technical leader who's not
really doing XP so management can know that they're really doing XP.

Frankly, Bill, it seems to me you're all over the map and it's getting to be
too much work for me to keep up. Your first set of critiques haven't been
resolved and you throw out a whole new set.

My wish is you would consolidate all of your concerns, work them all out to
some semblence of completion, then repost your StickyMinds article with the
same generous tone you've used in your posts here and hold the vinegar.

Chris


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 17:45:06 UTC
Permalink
Hi Chris,

----- On Wednesday, September 25, 2002 11:22 PM, Chris Morris wrote:

> Points I took from the original article:
>
> - XP lacks sound business practices.
Not what I said. XP, in the context of its "official" planning and
reporting practices, doesn't support what are generally accepted as sound
business practices. The specific quote is "XP's fundamental premise that
the software will be done when it's done and will cost what it costs is the
antithesis of sound business practice."

> - Insisting the customer be involved throughout development is
unreasonable.
For the customer who still has to do their "day job," yes.

> - XP wants to keep development in a less than mainstream state of
> craftsmanship.
Not what I said. XP, through the Whole Team practice 'seems to me to be
good evidence of XP's intent to keep software development in a craftsman
stage, in direct opposition to the business objective of seeing it evolve
into a more engineering-like discipline." One characteristic of an
engineering discipline is specialization.

> - XP's approach to planning by steering throughout dodges up-front
planning
> that the real world demainds.
Yep. That's the perception.

> - XP is adolescent and only wants management to leave it alone.
Yep. That's the perception.

> - XP won't commit to predicting the project and yet demands it be paid to
> work anyway.
Partly correct. The perception is "XP won't commit to predicting the
project and yet insists work should begin anyway."

> - XP should be about telling C-level how the project will progress
> beforehand.
*Must* is a better word. When you're working in a mainstream environment.

> - New prototyping tools could be a better solution for predicting a
project
> beforehand.
Could be an important part of the solution that would cut the Gordian knot.

> (btw, I like the combination of points 2 and 5...)
>
> The previous thread tackled some of these. Of those that were tackled, it
> seems some are still open, IMO:
>
> - You championed the prototype in your example, yet many of us couldn't
see
> any substantial difference between taking time prototype and taking time
to
> start an XP iteration. What do you think?

I think there's a difference, in mainstream management's mind, between
sending in an analyst and sending in a programmer.

> - You say we need to be able to predict a project's outcome to an exec
> before starting, we said you can as long as it's understood that that plan
> will most likely change. Does this satisfy your critique in the article or
> not?

The execs I know understand uncertainty and risk better than any programmer
I've ever met. That's the world they strive to survive in. In my
experience, we don't need an "in your face" explanation to the exec. That
just communicates that we think they're stupid.

> ... not to mention all of the original points that haven't been discussed.
>
> And now we get an entirely different summation post telling us that your
> main concerns are now:

Concerns haven't changed. Thought a different tack might help. Sorry if it
confused things.

> - XP doesn't have a good elevator sales pitch.
Yep. Not for the mainstream.

> - XP needs data telling us what Waterfall / V has over XP.
Standard requirement for any new thing that wants people to change from what
they have now. So I'd extend the need for Waterfall/V data to any existing
process/methodology you hope to replace.

> - XP needs better internal documentation to allow CFOs to audit the work.
Public documentation. Execs aren't going to care how the programmers
communicate among themselves and with the end-users they're working with.
They care that they get the information they need to perform their oversight
role.

> - XP is too dismissive to project management personnel and training.
Yep... of the training the project managers went through to become
effective.

> - XP needs to document warning signs of an XP technical leader who's not
> really doing XP so management can know that they're really doing XP.
Nope. Don't know where this came from. Let me know.

> Frankly, Bill, it seems to me you're all over the map and it's getting to
be
> too much work for me to keep up. Your first set of critiques haven't been
> resolved and you throw out a whole new set.
>
> My wish is you would consolidate all of your concerns, work them all out
to
> some semblence of completion, then repost your StickyMinds article with
the
> same generous tone you've used in your posts here and hold the vinegar.
>
> Chris

I understand your wish, Chris. As an entrepreneur and as a change agent in
large corporations, I've often wished someone would just show me the map.
The truth is, it's a messy problem space and we just have to keep trying to
make progress, overcoming objections as they're raised. I tried to raise a
couple of the fundamental ones. Addressing them will get you to the next
set, then the next, etc. That's business. I will stay engaged on the list
to monitor your progress and to help when I can. As I've said multiple
times, I would really like to see XP's programming/testing practices become
mainstream.

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 18:38:02 UTC
Permalink
Howdy, Bill. Perhaps I could suggest some rephrasings of your points?
Please tell me how true they are to what you are thinking:

On Thu, 2002-09-26 at 10:45, Bill Walton wrote:
> The specific quote is "XP's fundamental premise that
> the software will be done when it's done and will cost what it costs is the
> antithesis of sound business practice."

It would seem to me that it is precisely true that the software will be
done when it's done and cost what it costs. It would also seem to me
that sound business practice is to try to make predictions about the
future that are accurate enough to make good business decisions.

So is it fair to restate your point like this: "I don't understand how
XP would produce estimates of the quality needed to steer my business
well."

>
> > - Insisting the customer be involved throughout development is
> unreasonable.
> For the customer who still has to do their "day job," yes.

How about this for a restatement: "I don't see how the Customer can be
very involved in the project and still have time to do anything else.
How does that work?"


> > - XP wants to keep development in a less than mainstream state of
> > craftsmanship.
> Not what I said. XP, through the Whole Team practice 'seems to me to be
> good evidence of XP's intent to keep software development in a craftsman
> stage, in direct opposition to the business objective of seeing it evolve
> into a more engineering-like discipline." One characteristic of an
> engineering discipline is specialization.

How about: "I think software development should act more like other
sorts of engineering, like civil engineering, because we'd get benefits
X, Y, and Z. XP seems to point in another direction. Can it achieve same
benefits?"


> > - XP's approach to planning by steering throughout dodges up-front
> planning
> > that the real world demainds.
> Yep. That's the perception.
>
> > - XP is adolescent and only wants management to leave it alone.
> Yep. That's the perception.

How about, "Yep, that's my perception," or "Yep, that's the perception
I've seen among group X and group Y."


Are those fair ways to restate your points?


Thanks,

William

--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 19:59:28 UTC
Permalink
----- On Thursday, September 26, 2002 1:38 PM, William Pietri wrote:


> Howdy, Bill. Perhaps I could suggest some rephrasings of your points?
> Please tell me how true they are to what you are thinking:
>
> On Thu, 2002-09-26 at 10:45, Bill Walton wrote:
> > The specific quote is "XP's fundamental premise that
> > the software will be done when it's done and will cost what it costs is
the
> > antithesis of sound business practice."
>
> It would seem to me that it is precisely true that the software will be
> done when it's done and cost what it costs. It would also seem to me
> that sound business practice is to try to make predictions about the
> future that are accurate enough to make good business decisions.

Exactly

> So is it fair to restate your point like this: "I don't understand how
> XP would produce estimates of the quality needed to steer my business
> well."

That's not bad, but I'd say "I don't understand how XP would produce the
cost and schedule estimates I need to decide whether or not tackling this
problem right now is the best use of my resources."

I steer away from using the word "quality" whenever possible for a number of
reasons. First, it means so many things to different people. Second, it
can get people's backs up. I managed a test function for five years. I
never called it a quality function. Why? Here's how the conversation can
go very wrong: "Hi, I manage a quality function and your boss says you
could use my help." Way different reaction than I got with ""Hi, I manage a
test function and your boss says you could use my help." The first implies
they're producing crap. The second implies they might need some additional
hands to accomplish something they already knew they needed to do.


> > > - Insisting the customer be involved throughout development is
> > unreasonable.
> > For the customer who still has to do their "day job," yes.
>
> How about this for a restatement: "I don't see how the Customer can be
> very involved in the project and still have time to do anything else.
> How does that work?"

Perfect.

> > > - XP wants to keep development in a less than mainstream state of
> > > craftsmanship.
> > Not what I said. XP, through the Whole Team practice 'seems to me to be
> > good evidence of XP's intent to keep software development in a craftsman
> > stage, in direct opposition to the business objective of seeing it
evolve
> > into a more engineering-like discipline." One characteristic of an
> > engineering discipline is specialization.
>
> How about: "I think software development should act more like other
> sorts of engineering, like civil engineering, because we'd get benefits
> X, Y, and Z. XP seems to point in another direction. Can it achieve same
> benefits?"

Well said.

> > > - XP's approach to planning by steering throughout dodges up-front
> > planning
> > > that the real world demainds.
> > Yep. That's the perception.
> >
> > > - XP is adolescent and only wants management to leave it alone.
> > Yep. That's the perception.
>
> How about, "Yep, that's my perception," or "Yep, that's the perception
> I've seen among group X and group Y."

OK.

> Are those fair ways to restate your points?

Per the above, pretty much.

> Thanks,
>
> William

Thank you.
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 20:17:33 UTC
Permalink
Hi Bill,

You said something. William rephrased it. You replied:
> Exactly

You said something. William rephrased it. You replied:
> That's not bad ...

You said something. William rephrased it. You replied:
> Perfect.

You said something. William rephrased it. You replied:
> Well said.

You said something. William rephrased it. You replied:
> OK.

It's time for you to hire William as your editor.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 20:32:32 UTC
Permalink
On Thu, 2002-09-26 at 12:59, Bill Walton wrote:

> > Are those fair ways to restate your points?
>
> Per the above, pretty much.

Great! If you still have those questions or concerns, I encourage you to
post them in a format more like that. We are less likely to bristle and
you are more likely to get the information you seek.

As on Jeopardy, mailing lists go better when statements are put in the
form of a question.

William


--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 18:53:23 UTC
Permalink
Hi Bill,

> > - XP's approach to planning by steering throughout dodges up-front
> > planning that the real world demainds.
> Yep. That's the perception.

Do you share this perception?

> > - XP is adolescent and only wants management to leave it alone.
> Yep. That's the perception.

Do you share this perception?

The reason I ask is that I have a very hard time talking to one person
about another person's perception. If I can talk directly with a
person who has these perceptions, I have a decent chance of finding
some understanding.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 20:45:43 UTC
Permalink
Hi Dale,

----- On Thursday, September 26, 2002 1:53 PM, Dale Emery wrote:

> Hi Bill,
>
> > > - XP's approach to planning by steering throughout dodges up-front
> > > planning that the real world demainds.
> > Yep. That's the perception.
>
> Do you share this perception?

It's improving, but it's spotty. The problem derives from dealing with a
group rather than individuals. I'd have to say that it still feels like XP,
as a community, takes the position that the kind of planning that my clients
require is misguided, dishonest, etc.

> > > - XP is adolescent and only wants management to leave it alone.
> > Yep. That's the perception.
>
> Do you share this perception?

Again, it's improving, but spotty. I'd say the postings I've seen here in
the course of this discussion run the gamut, from one end of the spectrum.
There's more diversity in this community than I'd expected. On the one
hand, that's good. There are contributors here that, I think, have what it
takes to move XP forward into the mainstream business community. On the
other hand, that community expects to be able to pick up a package labled
"XP" and know what they're getting. I think that diversity leads to the
liklihood that many of them will be disappointed if they try it now.

> The reason I ask is that I have a very hard time talking to one person
> about another person's perception. If I can talk directly with a
> person who has these perceptions, I have a decent chance of finding
> some understanding.

I understand and agree. I'd be very happy to converse back channel.

Best regards,
Bill
***@jstats.com



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 18:55:50 UTC
Permalink
Hi Bill,

Ooops. Forgot one...

> > - XP won't commit to predicting the project and yet demands it be
> > paid to work anyway.
> Partly correct. The perception is "XP won't commit to predicting
> the project and yet insists work should begin anyway."

Do you share this perception?

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 20:54:55 UTC
Permalink
----- Original Message -----
From: "Dale Emery" <***@dhemery.com>
To: <***@yahoogroups.com>
Sent: Thursday, September 26, 2002 1:55 PM
Subject: Re: [XP] Day 2... From the author...


> Hi Bill,
>
> Ooops. Forgot one...
>
> > > - XP won't commit to predicting the project and yet demands it be
> > > paid to work anyway.
> > Partly correct. The perception is "XP won't commit to predicting
> > the project and yet insists work should begin anyway."
>
> Do you share this perception?

Ron's reply helped me to some extent, but I would have to say, overall, yes.
My expectation would be that I'd have trouble with getting most XP'ers to
commit to a project level estimate before programming begins. I think,
based on what I've read here, that most of the problem lies with the
experiences some of the contributors have had in the past with their
management re: the implications of not meeting those committments. I
understand that. I've felt that pain as well. Until I learned how to put
together time lines that included re-estimating tasks, contingency buckets,
etc.. In my experience, project management is really about managing up.
Most of the comments I've read here seem to reject that responsibility. No
offense intended. That's one of the skills we expect from project managers,
not from programmers.

Best regards,
Bill







To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Charlie Poole
2002-09-26 19:17:33 UTC
Permalink
Hi all,

Do we suffer from the lack of an "official" view of what XP is?

Like most of us, I cringe at the thought of there being such a thing,
but I'm wondering if it doesn't hurt us.

The ongoing discussion with Bill Walton has in several circumstances
included reference to the "official" practices - at first without the
quotes, and then with the quotes after we explained ourselves a bit.

Is it possible that some organization with a lot of money to spend
will hijack XP at a certain point and define it the way they want?
Might we end up with... say... 19 practices? More important, is there
anything we could do about it?

In case you can't tell, these are real questions that I don't
know the best answer to. ;-)

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kevin Lawrence
2002-09-26 19:45:23 UTC
Permalink
From: "Charlie Poole" <***@pooleconsulting.com>

>
> Is it possible that some organization with a lot of money to spend
> will hijack XP at a certain point and define it the way they want?
> Might we end up with... say... 19 practices? More important, is there
> anything we could do about it?
>

I wish that there were a single book that makes the business case for XP and
gives a concise summary of the values and practices and their benefits. I'd
buy multiple copies of this book to give to my customers, employees and
managers.

The book should reflect the latest thinking on XP and it should be white
with the words '2nd Edition' somewhere on the cover.

In my opinion of course ;-)

Kevin


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 19:53:05 UTC
Permalink
On Thursday, September 26, 2002, at 3:45:23 PM, Kevin Lawrence wrote:

> I wish that there were a single book that makes the business case for XP and
> gives a concise summary of the values and practices and their benefits. I'd
> buy multiple copies of this book to give to my customers, employees and
> managers.

I wrote a fairly nice 15,000 word thingie for Cutter entitled "The
Business of Extreme Programming". Wonder what I should do with it ...

> The book should reflect the latest thinking on XP and it should be white
> with the words '2nd Edition' somewhere on the cover.

That part I can't help you with.

Ron Jeffries
www.XProgramming.com
I could be wrong, but I'm not. --Eagles, Victim of Love


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 19:19:35 UTC
Permalink
On Thursday, September 26, 2002, at 1:45:06 PM, Bill Walton wrote:

>> Points I took from the original article:
>>
>> - XP lacks sound business practices.
> Not what I said. XP, in the context of its "official" planning and
> reporting practices, doesn't support what are generally accepted as sound
> business practices. The specific quote is "XP's fundamental premise that
> the software will be done when it's done and will cost what it costs is the
> antithesis of sound business practice."

Yes. The quote turns out to be an incorrect statement about XP.

>> - Insisting the customer be involved throughout development is
> unreasonable.
> For the customer who still has to do their "day job," yes.

Not necessarily: I've worked with many XP teams whose customers still
have a day job. And with many where the company has provided a
full-time customer. So it's neither unreasonable to expect full-time
involvement, nor impossible to do with less.

>> - XP wants to keep development in a less than mainstream state of
>> craftsmanship.
> Not what I said. XP, through the Whole Team practice 'seems to me to be
> good evidence of XP's intent to keep software development in a craftsman
> stage, in direct opposition to the business objective of seeing it evolve
> into a more engineering-like discipline." One characteristic of an
> engineering discipline is specialization.

Yes. Many of us do not think software development is, or should be,
engineering.

>> - XP's approach to planning by steering throughout dodges up-front
> planning
>> that the real world demainds.
> Yep. That's the perception.

But not the fact. It would be nice if people who might promulgate the
perception would study up on the subject first.

>> - XP is adolescent and only wants management to leave it alone.
> Yep. That's the perception.

That's not what it says in my book. It's not what it says in any of
the books, as far as I recall. We didn't say that. You did. That
troubles me.

>> - XP won't commit to predicting the project and yet demands it be paid to
>> work anyway.
> Partly correct. The perception is "XP won't commit to predicting the
> project and yet insists work should begin anyway."

Again, we didn't say that.

>> - XP should be about telling C-level how the project will progress
>> beforehand.
> *Must* is a better word. When you're working in a mainstream environment.

I'm aware of no "mainstream" process or practices that actually does
this better than XP does. Everywhere that I go, large company or
small, projects are failing to hit their "deadlines", followed by the
company ramping up heavier methodology, followed by projects failing
to hit their deadlines. Is your experience substantially different
from that?

>> - New prototyping tools could be a better solution for predicting a
> project
>> beforehand.
> Could be an important part of the solution that would cut the Gordian knot.

How do prototypes make commitments or produce predictions? I can see
that they might be an interesting way to come up with requirements,
but that's not what you're listing above.

<snip/>

>> - XP doesn't have a good elevator sales pitch.
> Yep. Not for the mainstream.

For all the well-known XP elevator pitches that you're familiar with,
please explain why they don't hunt.

>> - XP needs data telling us what Waterfall / V has over XP.
> Standard requirement for any new thing that wants people to change from what
> they have now. So I'd extend the need for Waterfall/V data to any existing
> process/methodology you hope to replace.

Straw man. There isn't any data recommending Waterfall over anything.

>> - XP needs better internal documentation to allow CFOs to audit the work.
> Public documentation. Execs aren't going to care how the programmers
> communicate among themselves and with the end-users they're working with.
> They care that they get the information they need to perform their oversight
> role.

So they ask for it and the team provides it.

>> - XP is too dismissive to project management personnel and training.
> Yep... of the training the project managers went through to become
> effective.

PMs, by and large, aren't delivering running software on time. This
must be some new use of the word "effective" that I wasn't previously
familiar with.

> I understand your wish, Chris. As an entrepreneur and as a change agent in
> large corporations, I've often wished someone would just show me the map.
> The truth is, it's a messy problem space and we just have to keep trying to
> make progress, overcoming objections as they're raised. I tried to raise a
> couple of the fundamental ones. Addressing them will get you to the next
> set, then the next, etc. That's business. I will stay engaged on the list
> to monitor your progress and to help when I can. As I've said multiple
> times, I would really like to see XP's programming/testing practices become
> mainstream.

Thanks for the good wishes. I, for one, would feel helped by articles
that better reflect what XP actually teaches rather than just
rehashing the mis-perceptions.

Ron Jeffries
www.XProgramming.com
The work teaches us. -- Richard Gabriel


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Chris Morris
2002-09-26 19:50:02 UTC
Permalink
> Concerns haven't changed. Thought a different tack might help. Sorry if
it
> confused things.

Well, it did confuse me. That's probably not hard to do, though ... Thanks
for the apology. Sorry, too if I came off a little gruff.

> I understand your wish, Chris. As an entrepreneur and as a change agent
in
> large corporations, I've often wished someone would just show me the map.
> The truth is, it's a messy problem space and we just have to keep trying
to
> make progress, overcoming objections as they're raised. I tried to raise
a
> couple of the fundamental ones. Addressing them will get you to the next
> set, then the next, etc. That's business.

Oh, I wasn't looking for The Map -- I was just looking for yours. I was
asking you to consolidate your concerns and follow through on addressing
each of them. When I first read your Day 2 post, it seemed to me like you'd
skipped over the unresolved ones and moved on to new ones.

Of course, a resolved concern to me may be that we simply agree to
disagree -- I'm not expecting agreement -- just some form of closure before
moving on.

The good news is in most of the points I posted, it seems I identified (or
closely identified) most of them. There was one at the end you disagreed
with, so I'll see if I can dig up the quote:

> > - XP needs to document warning signs of an XP technical leader who's not
> > really doing XP so management can know that they're really doing XP.
> Nope. Don't know where this came from. Let me know.

I got this from your quote here:

"At the very least, I think the XP leadership needs to publish prominently,
where execs would know about it and have ready access to it, a short list
(not a book) of "here there be dragons." You need to give them a comfort
level that they'll have the information they need when confronted with an
enthusiastic, apparently knowledgeable, but wrong-headed employee who is
liable, by your own estimation, to use XP in a way that will not likely
yield good results."

Summing this up was the most awkward one -- I was shooting for one-liners,
and at the time I found it hard to condense in my own words.

If I get time, I may throw out my thoughts on each of the other points, but
others have already started on that and I may not have anything to add.

As Dave Thomas likes to say, don't start something until you know how to
tell when your done. That's the main reason I wanted to sum up your
concerns, so we could have a point of origin for our discussions. We're done
when someone changes their mind on a point or we confirm an impasse.

Chris


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Buddha Buck
2002-09-26 19:54:12 UTC
Permalink
Bill Walton wrote:
> Hi Chris,
>
> ----- On Wednesday, September 25, 2002 11:22 PM, Chris Morris wrote:
>
>
>>Points I took from the original article:
>>
>>- XP lacks sound business practices.
>
> Not what I said. XP, in the context of its "official" planning and
> reporting practices, doesn't support what are generally accepted as sound
> business practices. The specific quote is "XP's fundamental premise that
> the software will be done when it's done and will cost what it costs is the
> antithesis of sound business practice."

If that is the case, then I question the soundess of that business
practice. There is always a certain amount of risk, a degree of
uncertainty in any software enterprise. XP openly acknowledges that
risk and uncertainty and allows the customer to make the business
decisions necessary to deal with that risk.

Sound business practices in a risky enterprise require evaluating and
managing that risk. Doing otherwise is foolish and unsound.

XP gives lots of tools for managing risk: XP gives the customer control
over the immediate priorities of the team; XP gives the customer the
option to cut their losses by taking what value there is in the product
after any iteration; XP provides feedback on a daily, weekly, monthly,
etc level about what the true level of risk is. I'm sure there are
other features of the XP process that help manage and deal with risk.

>>- Insisting the customer be involved throughout development is
>
> unreasonable.
> For the customer who still has to do their "day job," yes.

XP would like someone available who can answer questions like "What,
exactly, does this requirement mean?" or "Does this behavior work for
you?", etc, and answer them from the point of view of the "Goal Doner".
If it is possible for that Goal Doner to continue to do their "day
job" while being available to clarify the Goals for the XP team, the
developers would prefer that to having no one there, and the Goal Doner
would prefer that to having to dedicate themselves full-time to working
alongside the developers without being able to do their "day job".

>>- XP wants to keep development in a less than mainstream state of
>>craftsmanship.
>
> Not what I said. XP, through the Whole Team practice 'seems to me to be
> good evidence of XP's intent to keep software development in a craftsman
> stage, in direct opposition to the business objective of seeing it evolve
> into a more engineering-like discipline." One characteristic of an
> engineering discipline is specialization.

I tend to think that it's entirely possible that software development is
a discipline which does not benefit from specialization.

>>- XP's approach to planning by steering throughout dodges up-front
>
> planning
>
>>that the real world demainds.
>
> Yep. That's the perception

Before you came along and engaged us in dialogue, one of the more common
topics for heated discussion was the relationship between XP and the
Rational Unified Process -- the process toolkit that is generally
accepted (by management, at least) as the "proper process" for software
development. Very often, when people are evaluating XP, they compare
their perception of XP (which is often wrong) with their perception of
RUP (which is also often wrong), and say "XP is not RUP, therefore it's
bad". In truth, RUP (the accepted methodology) also favors steering in
mid-process and has an iterative structure similar to XP.

XP is based on the premise that experience has shown that the "real
world demands" for up-front planning are often erroneous illconceived.
XP will work when all the planning is done up-front, but XP is making
the bet that the planning done up-front won't be accurate by the time
the project is done. Hence, the emphasis on being able to steer in
mid-process.


>>- XP is adolescent and only wants management to leave it alone.
>
> Yep. That's the perception.
>
>
>>- XP won't commit to predicting the project and yet demands it be paid to
>>work anyway.
>
> Partly correct. The perception is "XP won't commit to predicting the
> project and yet insists work should begin anyway."

XP takes a realistic view towards software estimates and won't commit to
what it can't reliably predict based on the information at hand. XP
views the best way to get good information to base better predictions on
is to do real work on the project.

>>- You say we need to be able to predict a project's outcome to an exec
>>before starting, we said you can as long as it's understood that that plan
>>will most likely change. Does this satisfy your critique in the article or
>>not?
>
>
> The execs I know understand uncertainty and risk better than any programmer
> I've ever met. That's the world they strive to survive in. In my
> experience, we don't need an "in your face" explanation to the exec. That
> just communicates that we think they're stupid.

What, in your opinion, are the exec's looking for in your prediction? A
simple "go/no-go", or "60% chance of getting all the requirements done
by deadline, 80% for 80% of the requirements, 95% for 50% of the
requirements"?






To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 20:08:54 UTC
Permalink
Hi Bill,

> > - XP won't commit to predicting the project and yet demands it be
> > paid to work anyway.
> Partly correct. The perception is "XP won't commit to predicting
> the project and yet insists work should begin anyway."

Here's what I'm seeing. Managers want predictions that have a certain
level of confidence. Programmers offer predictions with a certain
level of confidence. The levels of confidence don't match. The
managers want more confidence than the programmers offer. The
programmers offer less confidence than the managers want.

In response, each amplifies the confidence gap and polarizes the
conversation. Each sees the other as unreasonable and irresponsible.
Managers say, "You programmers refuse to commit to *anything*!
That's unreasonable! That's irresponsible!" Programmers say, "You
managers want predictions that are *perfect*! That's unreasonable!
That's irresponsible!"

Round and round.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-09-26 13:28:01 UTC
Permalink
Bill Walton said:
> I've come to realize, through interaction with this group,
> that XP practitioners, particularly those with real
> experience, are taking a much more realistic approach to
> project communication than the position being hyped in the
> press and programmers I've talked to and seen on this list.

As you say, words matter. In your words I hear you saying that published
articles that say positive things about XP are hype. Is your negative
article any less hype? In your words I hear you saying that programmers on
this list are unrealistic but XP practitioners on this list are realistic.
How do you decide to which group a poster on this list belongs?

I know you joined this list a little before posting your Sticky Minds
article, but is that where you learned what XP is and how it's been
presented to business executives? Have you read Extreme Programming
Explained or any of the other XP books? Do you expect that the conversation
between a bunch of programmers should be appropriate for selling an idea to
an executive? To put it simply, I'm wondering where, and if, you learned
enough about XP to make any informed criticism.

> My point is that there's a communication problem. Your last
> sentence is a good example, and please don't take offense to
> this because it's meant entirely in goodwill. When you say
> *within* the project, I think you mean "among the programmers
> and those with whom they have direct interaction." My point
> is that that leaves out a whole bunch of people who may
> consider themselves part of the project, right up to the
> people who funded it and are responsible for seeing that that
> money is spent wisely. Words matter.

Yes, I'm making a distinction between people who are involved in the project
and the people who, as you describe, have "day jobs" and no time to be
involved in the project but want to be able to track what's going on in it.

But I also begin to see why you have such a hard time pitching something
like XP to executives. You ignore direct questions. If someone says
something specific, you complain they leave the rest of the world out of
their statement. If someone makes a distinction, you complain that they're
offending certain people. But you seem to be dodging responding to the
points that others make, only finding fault with the way it's worded.

I am having a very hard time not throwing the bozo bit. You keep using the
word "engaged." Are *you* engaged in this discussion? If so, why do you
not answer the questions asked of you? Or are you just trolling, seeing
what you can stir up? You raise good points about the "selling" of XP, but
you don't seem very interested in pursuing those points. To me, you seem
more interested in "scoring points" by dissing others on this list.

Sorry for the rant, but this conversation is starting to seem meaningless to
me and, as I've put thought and energy into making it a meaningful
communication, I find that frustrating.

- George

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Fuqua, Andrew (ISSAtlanta)
2002-09-26 14:13:15 UTC
Permalink
> From: Bill Walton
> It lacks an element of
> respect for our co-workers. While I don't remember
> addressing them specifically in our exchanges, let's take a
> sec to talk about project managers. They have a pretty
> widely recognized and valued role in the mainstream. XP
> takes the position that they're optional.

XP does not address everything that is needed to be done in order to successfully develop and ship software. There is much that is out of XP's scope. One should not assume that XP is against those jobs or the people that do them.

The coordination necessary between large numbers of teams is but one example. Take my company as an example. We have hundreds of engineers organized into a few divisions divided into dozens of departments managed by dozens of managers and consisting of scores of teams producing a handful of product lines containing dozens of products. And throw in the usual assortment of marketing and product managers and other stuff a typical company needs. A typical hierarchical organization.

Does this company need project managers? Of course they do. How many? Does each department need one? No. Does the project manager need to get into the details at the level the programmers work? Of course not.

My company only has a couple teams doing XP, but even if every team did XP, we'd still need project managers. These guys don't care about cards or stories or pairs or unit tests. They care about projects and dependencies among projects. They care about when the next release is and about the coordination and handoffs between development, QA, the guy that burns the master golden CD and the company that duplicates CDs, prints the inserts, builds the package, applies the shrink-wrap and fulfills the orders. They are interested in the overall schedule for the marketing materials and for the release date for the next fix pack. They care about the dependency between Department 9 in Division 1 and Department 32 in Division 4 because 9's product is supposed to manage 32's product. And they would like a demonstrable measure of progress, which an XP team can give them in spades. Project managers I've worked with are thrilled that my XP team's progress reports are far more reliable than
traditional process progress reports.

My team of 4 programmers has many customers who have each given us a set of must-have and a set of nice-to-have feature requests (stories). Each of those customers wants to know when their sets of features will be done. So I produce a MS Project schedule that can usually fit on a page or two, with that HIGH-LEVEL detail. And as with any good XPer, I explain that because I allow customers to change their mind as they learn and as the market changes, the schedule is an estimate, not a commitment. Sometimes, for really important features or customers, a project manager might track some dependency. But it is usually not cost effective for project managers to track details for every 4 person team.

The disconnect / miscommunication between XPers and those criticizing XP is often one of scope.

regards
andrew fuqua

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-09-26 14:42:33 UTC
Permalink
Bill Walton
> I have this picture in my mind
> of the exec's response to hearing that she needs to meet with
> each team on a very regular basis and to get status on
> projects, she'll be able to go look at the team's card stack
> and see the working pieces of the application. That's not
> the way oversight works at large companies.

And that's not the way it would work with XP in a large company. As has
been stated numerous times, if the executive team needs a summary report, by
all means, write that summary report. Your argument "don't hunt."

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Lowell Lindstrom
2002-09-26 14:51:54 UTC
Permalink
> We know that most IT projects that fail do so
> due to missed or misunderstood requirements.

I am not sure that we *know* that most fail due to this. But it is
certainly a major problem and contributor and there are studies that
conclude that. I would add changing requirements, unrealistic expectations,
and bad communication as equal contributors to failed projects.

There are many XP teams out there that are succeeding with the requirements
challenge. Some just use cards, but many have added other, often
traditional practices to explore, capture, and communicate requirements.
Learning these best practices is part of the evolution of XP. Applying
them is balance between changing the organization to work in a simpler way
and adapting XP when that is not possible, which is often.

A few practices I am aware of are Focus Groups (Sam Bayer presented this at
XPU'01) for incremental end user feedback. Upfront, there are various
overall product stratgy and requirements processes that I have seen, some
that are consistent with XP/Agile Values, some which are not. Both seem to
work with varying degrees of success.

I think controlling hype and communication in the market place falls into
the unrealistic expectations category. Take your article. There was no way
for anyone to control what you wrote. That is your editorial judgement as
it should be. You could have posted a draft here, but that would be pretty
unusual for an author. I do not ever recall that being done.
So, to expect that everyone who writes about XP will seek some sort of
community view may be desirable (debatable), but is not realistic.

The key is that this a forum that can help overcome challenges in selling
and applying XP and it has done so in the past. But the constructive focus
needs to be on the specific challenge that you are facing, not what is wrong
with XP (or anything else), IMHO.

Lowell

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
kentlbeck
2002-09-26 17:08:03 UTC
Permalink
I'll follow up Lowell's comment by saying, Bill, that if you and I
were sitting together, here's how I predict the conversation would
go.

B: "What happens when you have 10 XP projects? The execs won't want
to come every week for the planning meeting."
K: "Okay, don't do that. What will they do?"
B: "They might come to quarterly reviews, look at progress, and set
priorities."
K: "Okay."
B: "And what if you have 100 XP projects? How will the CEO be able
to keep track of all that?"
K: "What would you do?"
B: "It's obvious. I'd X, Y, and Z based on my experience as a
project manager in large companies."
K: "Okay."
B: "But the XP literature doesn't say anything about these issues."
K: "That's because none of us is a project manager in a large
company (at least not the ones who write.) How about if you try your
idea for six months and then write the book yourself?"

Get sensible people together, focus them on producing value, let
them do their thing, and help them learn quickly. Nothing is
forbidden that is focused on value. And I assume that everyone must
contribute their wisdom for the whole thing to work. If your wisdom
isn't represented here, it's because you haven't contributed it yet
(this is the old "camel in the tent p5g out vs out of the tent p5g
in" strategy.)

Kent


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 19:23:20 UTC
Permalink
----- Original Message -----
From: "kentlbeck" <***@csi.com>
To: <***@yahoogroups.com>
Sent: Thursday, September 26, 2002 12:08 PM
Subject: [XP] Re: Day 2... From the author...


> I'll follow up Lowell's comment by saying, Bill, that if you and I
> were sitting together, here's how I predict the conversation would
> go.
>
> B: "What happens when you have 10 XP projects? The execs won't want
> to come every week for the planning meeting."
> K: "Okay, don't do that. What will they do?"
> B: "They might come to quarterly reviews, look at progress, and set
> priorities."
> K: "Okay."
> B: "And what if you have 100 XP projects? How will the CEO be able
> to keep track of all that?"
> K: "What would you do?"
> B: "It's obvious. I'd X, Y, and Z based on my experience as a
> project manager in large companies."
> K: "Okay."
> B: "But the XP literature doesn't say anything about these issues."
> K: "That's because none of us is a project manager in a large
> company (at least not the ones who write.) How about if you try your
> idea for six months and then write the book yourself?"

Not bad. Pretty close I'd say. But it misses the point I've tried to make.
If XP hopes to "cross the chasm" into large projects in large companies,
into the mainstream, XP has to provide a total solution, not pieces that
those people are supposed to figure out how to fit together. I do not mean
to sound flippant or disrespectful, Kent, but I think you should give
Moore's book a read. It's a small book, and I think it will give you an
additional, important perspective on the continued growth of the XP
practice..

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dale Emery
2002-09-26 19:39:32 UTC
Permalink
Hi Bill,

> If XP hopes to "cross the chasm" into large projects in large
> companies, into the mainstream, XP has to provide a total solution, not
> pieces that those people are supposed to figure out how to fit
> together.

What if we left XP as is, and showed how we've integrated it into a
number of different total solutions at different companies?

Or what if we left XP as is, and integrated it into a larger solution?
For example, XP has recently been integrated into RUP. Someone posted
the URL here a week or two ago.

If we were to try to make XP more comprehensive, XP would lose some of
the focus that makes it so valuable. Jerry Weinberg's Law of
Raspberry Jam applies here: the wider you spread it, the thinner it gets.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kevin Lawrence
2002-09-26 20:53:38 UTC
Permalink
Dale,

>
> > If XP hopes to "cross the chasm" into large projects in large
> > companies, into the mainstream, XP has to provide a total solution, not
> > pieces that those people are supposed to figure out how to fit
> > together.
>
> What if we left XP as is, and showed how we've integrated it into a
> number of different total solutions at different companies?
>
> Or what if we left XP as is, and integrated it into a larger solution?
> For example, XP has recently been integrated into RUP. Someone posted
> the URL here a week or two ago.
>
> If we were to try to make XP more comprehensive, XP would lose some of
> the focus that makes it so valuable. Jerry Weinberg's Law of
> Raspberry Jam applies here: the wider you spread it, the thinner it gets.
>

The Cross the Chasm (CTC) model addresses the Law of Rasberry Jam quite
nicely and in fact advocates not spreading yourself too thin.

If you subscribe to the CTC model for technology adoption, the people on the
other side of the chasm will only adopt the new technology if they see
people who are 'just like them' adopting it first. The way you overcome this
catch-22 is to target a narrow market segment and make it really easy to
adopt in this segment by making a 'whole product' available. The whole
product includes everything that the buyer needs to be successful, not just
the thing you are selling. You do the same for the next market and the next
market until the thing builds up a self-sustaining momentum. What
constitutes the whole product will vary by market.

For example, let's say the initial market is consulting companies building
small, e-commerce sites using java application servers. A company like that
would probably need a customized version of JUnit that knows about the top 3
application servers and top 3 databases. They would need to be able to test
the resulting web pages. They would need clear guidance as to the role of
the customer and a step-by-step guide for how to gather stories - maybe even
a template project with prepared stories that they can customize as
necessary. The kit could probably also include pre-built acceptance tests
that prove concurrency and performance and that the interface to the credit
card processing works correctly. They should be able to run the install
program and CVS, Cruise Control, JUnit and Eclipse will all be set up and
ready to go. The whole thing should be advertized in Small E-Commerce Sites
Weekly.

In this target market you should be able to clearly point to the alternative
and say "our thing is better than that because ...."

BTW that example was for illustration only. I don't necessarily think that
this is the best first market. Also note that focusing most of your
attention on the early majority in one market does not mean that you can't
also be successful in the wider market of early adopters.

Other examples of a small enough beach head market could be "Banks on Wall
Street (lots of Sun & Unix. precise financial calculations and large
transaction volumes important) or "Developers of Device Drivers for Windows
XP". The idea is to choose a small enough market where the people in that
market read the same publications, go to the same shows and have similar
problems. Once the CIOs of Chase and Deutsche Bank have got the XP bug, you
can bet that the CIOs of all the other banks are going to take an interest.
Onces all the banks are doing XP, they are gonna talk to their buddies in
insurance.

Sure you can get all the whole product now with a little patience and a lot
of investigative work but the so-called early-majority is rarely willing to
do that. I think it's sometimes hard for us to sympathize with this point of
view because, almost by definition, the kind of people who hang out on a
list like this are early adopters. One thing CTC makes clear is that the
early majority don't think like early adopters. This is another catch-22
because the lessons learned in the early days of a new technology do not
apply to the later stage. That's why so many new technologies "fall into the
chasm". It also doesn't help that the people who come up with the new
technologies are themselves early adopters.

Having said all that, I am not sure if widespread adoption is what I
personally want for XP. Like another poster, part of me wants to see XP very
successful because I want my industry to be successful - but part of me
enjoys the competitive advantage of being one of the few. On the whole, I
would secretly like XP to be hugely successful just as I do for any
technology that I *early adopt*.

Excuse my long-windedness, Geoffrey Moore was on the advisory board of my
last company so I used to hear this stuff all the time.

Kevin



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-09-26 19:55:14 UTC
Permalink
On Thu, 2002-09-26 at 12:23, Bill Walton wrote:
> > K: "That's because none of us is a project manager in a large
> > company (at least not the ones who write.) How about if you try your
> > idea for six months and then write the book yourself?"
>
> Not bad. Pretty close I'd say. But it misses the point I've tried to make.
> If XP hopes to "cross the chasm" into large projects in large companies,
> into the mainstream, XP has to provide a total solution, not pieces that
> those people are supposed to figure out how to fit together. I do not mean
> to sound flippant or disrespectful, Kent, but I think you should give
> Moore's book a read. It's a small book, and I think it will give you an
> additional, important perspective on the continued growth of the XP
> practice..

Since it's in the bibliography of Kent's book "XP Explained," I'm
guessing he's read it.

Moore certainly say things like, "To get to the right of the chasm--to
cross into the mainstream market--you have to... [have] the whole
product be readily available from the outset." And if XP were Extreme
Programming Incorporated, with Kent Beck as CEO, I'd agree that Kent
would be making a serious marketing error in not offering Kent-branded
end-to-end solutions about now.

But could it be that Kent chose a different path? It seems that other
people (Object Mentor, Thoughtworks, Rational, various authors) have
recognized the need of those across the chasm from we early adopters and
are working busily to fill them.

Although I agree completely the XP community could play a big role to
play in helping XP cross the chasm, I think that Moore's advice for a
product company is not directly applicable. As somebody else pointed out
in this thread, our incentives as members of the XP community are very
different than employees of a product company.


William





--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-09-26 14:57:09 UTC
Permalink
I would have to agree. Nobody is getting arrested for making bad or even misinformed decisions. They are getting arrested for apparent illegal "cooking of books" and fake transactions. The effectiveness of the CEO/CFO has always been intensely scrutinized by the shareholders. No CEO worth her salt is going to shy away from something that has satisfied her on the merits, just because she thinks she's going to go to jail for it, because she knows she won't.

> -----Original Message-----
> From: Kyle Cordes [mailto:***@kylecordes.com]
> Sent: Wednesday, September 25, 2002 7:50 PM
> To: ***@yahoogroups.com
> Subject: [XP] fiduciary oversight
>
>
> From: "Laurent Bossavit" <***@bossavit.com>
>
> > > The world we work in today is dominated by intense scrutiny and
> > > legislation regarding the effectiveness of the CEO / CFO in their
> > > fiduciary oversight role.
>
> > Now *that* stopped me in my tracks. I don't think I work in that
>
>
> It is also a *fantastic* way to torpedo an idea... find a way to
> insinuate that the idea could be not merely a bad idea but a breach of
> fiduciary duty and legally perilous.
>
> What if I were to say that using a whiz-bang prototype tool to quite
> possibly produce totally incorrect expectations on the part of a
> customer, is a dangerous thing to do in an environment with great
> scrutity on CEO/CFO fiduciary oversight? That doing so might
> set things
> up to have a date slip on crucial product, make the firm miss revenue
> targets, trigger shareholder lawsuits, get the CFO indicted, etc.?
> Would that be a good argument?
>
> (No, it would not. Let's talk about the merits of ideas, not use the
> "post-Enron" business environment to spread FUD.)
>
> Kyle Cordes
> www.kylecordes.com
>
>
>
> To Post a message, send it to: ***@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-***@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-09-26 15:07:45 UTC
Permalink
Bill,

You make some very valid points on the business side.(This where I'm supposed to say "but....")

I think that in the case of fiduciary responsibility, you are looking in the wrong direction. Nobody is going to get investigated for choosing methodology x. Fired, maybe, but hey that's why there are golden parachutes.

Most CEO's really aren't going to get involved in what programming methodology their different groups are using. I would guess that you are really more worried about the next level down. Not that this is a misdirected worry, but that oversight and the senate getting involved in lynching you aren't really problems here.

I get the impression that you are, like me, one of those dreaded "managers". I have found that any gaps in how XP practices communicate or "play" to the uppers can easily filled by adhering to the four principles of XP. Execs like to get reports about how things are going. Great, give them reports that translate what is going on into "execuspeak". I spend at least 1/3 of my week doing just that. It gets to be fun after a while.

Steve

> -----Original Message-----
> From: Bill Walton [mailto:***@jstats.com]
> Sent: Thursday, September 26, 2002 8:31 AM
> To: ***@yahoogroups.com
> Subject: Re: [XP] Day 2... From the author...
>
>
>
> ----- On Wednesday, September 25, 2002 5:51 PM, Laurent
> Bossavit wrote:
>
> > Bill:
> >
> > > The world we work in today is dominated by intense scrutiny and
> > > legislation regarding the effectiveness of the CEO / CFO in their
> > > fiduciary oversight role.
> >
> > Now *that* stopped me in my tracks. I don't think I work in that
> > world. I work in the world where they let Jean-Marie Messier away
> > with murder, and France Telecom piss away 70 billion eurodollars.
>
> Oops. It's easy to forget about reach. I can only address the U.S.
> environment, where Enron, Anderson, WorldCom, and Tyco
> dominate the news.
> Where the S.E.C. is investigating the retirement package of
> Jack Welch, one
> of the icons of the American management scene; someone who,
> to my knowledge,
> has never had a smudge on his record. Context is everything.
>
>
> > > At the very least, I think the XP leadership needs to publish
> > > prominently, where execs would know about it and have
> ready access to
> > > it, a short list (not a book) of "here there be dragons."
> >
> > Why not a book ?
>
> A book would be fine, but the exec shouldn't have to read the
> book to get a
> high level understanding. That should come across clearly in the list
> which, if it's valuable, will cause execs to want to spend
> the time to learn
> more.
>
> Best regards,
> Bill
>
>
> To Post a message, send it to: ***@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-***@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill Walton
2002-09-26 18:43:27 UTC
Permalink
----- On Thursday, September 26, 2002 10:07 AM, Steve Ropa wrote:

> I think that in the case of fiduciary responsibility, you are looking in
the wrong direction. Nobody is going to get investigated for choosing
methodology x. Fired, maybe, but hey that's why there are golden
parachutes.

I agree. My point is about the obstacles to adopting a new technology.

> Most CEO's really aren't going to get involved in what programming
methodology their different groups are using. I would guess that you are
really more worried about the next level down. Not that this is a
misdirected worry, but that oversight and the senate getting involved in
lynching you aren't really problems here.

Yes, that group a level or two down is the one that's going to, or not going
to, take the risk of adopting XP based, at least in part, on their
perception of how it would be viewed by their superiors.

> I get the impression that you are, like me, one of those dreaded
"managers".

I have been. Not right now.

> I have found that any gaps in how XP practices communicate or "play" to
the uppers can easily filled by adhering to the four principles of XP. Execs
like to get reports about how things are going. Great, give them reports
that translate what is going on into "execuspeak". I spend at least 1/3 of
my week doing just that. It gets to be fun after a while.

I agree. Anyone who wants to make the effort can pull good stuff from XP
practices and adapt them to their own situation. But I also note that that
makes you, because you're willing to piece together your own solution, an
early adopter as opposed to the mainstream (in Moore's terms).

Best regards,
Bill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-09-26 18:45:40 UTC
Permalink
> -----Original Message-----
> From: William Pietri [mailto:***@scissor.com]
> Sent: Thursday, September 26, 2002 12:21 PM
> To: ***@yahoogroups.com
> Subject: Re: [XP] Re: Day 2... From the author...
>
>
> On Thu, 2002-09-26 at 09:08, banshee858 wrote:
> >
> > These lazy suits can get up and read a book from
> time-to-time! None
> > of Kent's books (white or green) take that long to read.
>
> Although I've had this feeling myself, I should point out
> that different
> people learn differently.
>
> We geeks are on the high end of the curve when it comes to things like
> reading speed and reading skills. To many managers, "Just read this
> short 300 page book," sounds like as much fun as, "Can you speak in
> front of an audience of 100 this afternoon?" or "Joe and Steve are mad
> at one another. Could you get them to make up and get back to work?"
> would to your typical geek.
Very well said. Except Joe and I are no longer mad at each other ;-)

>
> So if a manager will learn best from a 3-page summary or a 30-minute
> presentation or a dramatic skit, I'm generally glad to do
> what I can for
> them. I'll certainly recommend formats that I think will best
> convey the
> information, but if the manager learns best through tap-danced morse
> code, I'm willing to go get tap shoes.
>
This is, in fact why there is usually something called an "Executive Summary" at the front end of most large reports. Whether we choose to believe it or not, an executives life is a lot more than jetting around in first class and going to jail. They usually get to where they are based on some skill or talent that is superlative. Those that get there purely through politics tend to self-destruct. Either way,they are almost always incredibly busy. I have found that one reason some executives have difficulty with the idea of insisting on a 40 hour week is because they have never worked a 40 hour week in their lives.

Steve

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-09-26 19:41:35 UTC
Permalink
Bill Walton keeps asking about:
> Specifically the overworked customer problem I talked about
> in the column and here more than once.

Is there really an "overworked customer problem" or is that just something
you fear? Could it be that the customer can spend 8 hours a day available
to the developers for questions and 8 hours a day doing their normal work
and still spend only 8 hours a day doing it?

- George

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-09-26 19:51:23 UTC
Permalink
On Thursday, September 26, 2002, at 3:41:35 PM, Dinwiddie, George wrote:

> Bill Walton keeps asking about:
>> Specifically the overworked customer problem I talked about
>> in the column and here more than once.

> Is there really an "overworked customer problem" or is that just something
> you fear? Could it be that the customer can spend 8 hours a day available
> to the developers for questions and 8 hours a day doing their normal work
> and still spend only 8 hours a day doing it?

There is such a problem. The first C3 customer overworked. And she had
only the one job. Overworking is a function of exactly one thing:
working too much. It is not caused by too much to do, nor by too
little time. It is caused by working too much. That is always a
choice.

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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
m***@pobox.com
2002-09-26 20:18:34 UTC
Permalink
Hi, Bill,

>Not bad. Pretty close I'd say. But it misses the point I've tried to make.
>If XP hopes to "cross the chasm" into large projects in large companies,
>into the mainstream, XP has to provide a total solution, not pieces that
>those people are supposed to figure out how to fit together. I do not mean
>to sound flippant or disrespectful, Kent, but I think you should give
>Moore's book a read. It's a small book, and I think it will give you an
>additional, important perspective on the continued growth of the XP
>practice..

XP doesn't hope to cross the chasm.

XP isn't a total solution.

XP isn't a panacea.

And I dare to add:

ditto for prototyping tools.

XP works well for a lot of developers, customers, and managers on a
wide variety of projects. If you are afraid it won't work for yours,
either deal with that fear, or find an approach you're not afraid of.

Peace,
--Carl
--

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-09-26 20:28:13 UTC
Permalink
Dale Emery said
> > Oh, I'd agree! If XP were a thing that could sell, and if it were
> > trying to sell to the mainstream, it should do those
> things. But since
> > it's not a person or a company, I don't think that it should.
>
> I'm taking "sell" to mean something broader than just a
> selling product or service to a customer for money. I see
> messages here frequently from people wondering "how do I
> convince my manager/colleagues to do/try/acknowledge XP."
> That seems like selling to me. And I'm guessing that those
> managers and colleagues often fit into the category "mainstream."

Yes, but it's still not XP doing the selling. It's the person trying to
introduce XP in his/her workplace. And that selling has to be finely tuned
to the person/people being sold if it's to be effective. Wouldn't you
agree?

- George

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kevin Lawrence
2002-09-26 20:51:17 UTC
Permalink
> >
> > I'm taking "sell" to mean something broader than just a
> > selling product or service to a customer for money. I see
> > messages here frequently from people wondering "how do I
> > convince my manager/colleagues to do/try/acknowledge XP."
> > That seems like selling to me. And I'm guessing that those
> > managers and colleagues often fit into the category "mainstream."
>
> Yes, but it's still not XP doing the selling. It's the person trying to
> introduce XP in his/her workplace. And that selling has to be finely
tuned
> to the person/people being sold if it's to be effective. Wouldn't you
> agree?
>
> - George
>

Maybe a good comparison here is to compare Smalltalk with Java, or Linux
with Windows, or RDBMS with ODBMS.

In each case we would probably happily advocate one of those technologies
over the other because we think it increases the odds of our industry being
seen as successful and, more personally, it increases the odds of working
with our preferred technology at future jobs. The fact that we don't have a
financial interest in the success of a tecchnology is irrelevant. We are
still selling it and the same selling techniques will be successful.

Kevin


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

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