[AM] Article of Interest in CIO Magazine

[p***@aol.com]

Here's a "heads up" regarding an article that might be of interest, regarding
the manner in "input biases" may affect the decisions we make. Entitled "Bias
Beware", it appeared in the MARCH 1, 2004 ISSUE OF cio mAGAZINE. It was
written by Maurice Schweitzer, a professor at the Wharton School of Business at the
University of Pennsylvania (one of my old stomping grounds). Briefly, it
describes how decisions are sometimes skewed by what the writer calls "input
bias", which often leads decision makers to confuse "quantity" with "quality". One
of the examples cited was concerned with decisions regarding software
products; here's a short quote:

"If you're trying to choose between two software packages, it might make
sense to have both tested by employees who don't know how long took to build or
how much it cost to develop--the kind of input data that could bias their
judgment".

I believe the article describes a factor that might play a major role in a
manager's or client's decision of whether to "play or pass" on agile development
methoologies. The article gave me a new perspective on what might be going on
in the minds of those considering an agile approach. Considering what some
have called the "mushy" principles of Agile Modeling, and the dearth of
objective evidence of its obvious benefits, this article might be food for thought
regarding how agile development is described to potential adopters.

Something to hink about...

And now, we return to your regular programming...

egards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Michael Vizdos]

Just looking at that magazine last night... It has on the cover, "Bursting
the CMM Hype" How to probe CMM claims, 12 critical questions to ask. Have
not read it yet but on my list. Might be good to discuss here.

- mike

-----Original Message-----
From: ***@aol.com [mailto:***@aol.com]
Sent: Saturday, March 06, 2004 9:31 AM
To: ***@topica.com
Subject: [AM] Article of Interest in CIO Magazine

Here's a "heads up" regarding an article that might be of interest,
regarding the manner in "input biases" may affect the decisions we make.
Entitled "Bias Beware", it appeared in the MARCH 1, 2004 ISSUE OF cio
mAGAZINE. It was written by Maurice Schweitzer, a professor at the Wharton
School of Business at the University of Pennsylvania (one of my old stomping
grounds). Briefly, it describes how decisions are sometimes skewed by what
the writer calls "input bias", which often leads decision makers to confuse
"quantity" with "quality". One of the examples cited was concerned with
decisions regarding software products; here's a short quote:

"If you're trying to choose between two software packages, it might make
sense to have both tested by employees who don't know how long took to build
or how much it cost to develop--the kind of input data that could bias their
judgment".

I believe the article describes a factor that might play a major role in a
manager's or client's decision of whether to "play or pass" on agile
development methoologies. The article gave me a new perspective on what
might be going on in the minds of those considering an agile approach.
Considering what some have called the "mushy" principles of Agile Modeling,
and the dearth of objective evidence of its obvious benefits, this article
might be food for thought regarding how agile development is described to
potential adopters.

Something to hink about...

And now, we return to your regular programming...

egards,

Pete
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

Mike:

This issue of CIO seems to have more than the usual number of
software-related articles. In addition to the one I originally recommended ("Bias Beware"),
there is Jack Keen's Real Value column, "Avoiding the TCO Trap". TCO is
frequently a "straw man" when dealing with new approaches to software development:
the dearth of historical data pertaining to agile methodologies I mentioned in
my original post makes TCO a convenient target, and a means to distract
decision makers from more appropriate issues. The problem with TCO as a measurement
tool is that it may paint an invalid picture of the quality of the development
effort, and of course, like emerging requirements, it cannot be predicted with
any accuracy. From my perspective, if 90% of the TCO of an application system
is borne after it has been deployed, as has been suggested, it says more
about an inappropriate system design and architecture than it does about the
difficulty in predicting the future requirments of the system.

The cover article you mentioned, "Bursting the CMM Hype", was particularly
nteresting to me, as I spent a couple of years as the Director of Quality
Assurance at Memorex Corporation in the late 1970s. I've had some concerns about the
validity of the CMM since its inception several years ago. I recently
revisited the CMU CMM site to find out how much had changed since a couple of years
ago. It seems pretty much the same as it was then, except that its ssponsors
and practitioners seem to be "owning up" to its not being the "end all, be all",
to their great credit, regarding software quality.

Anyway, just another great issue of CIO Magazine.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Post by p***@aol.com
From my perspective, if 90% of the TCO of an application system
is borne after it has been deployed, as has been suggested, it
says more about an inappropriate system design and architecture
than it does about the difficulty in p redicting the future
requirments of the system.

What it says to me is that most people focus on the wrong thing:
the initial cost of the system. One of my standard soapbox
speeches is about how most projects focus entirely on the
expensive pause at the beginning of the project (i.e.
development) and spend far too little time focussing on the
really important part from the business's perspective: the
profits (or other benefits) that the system generates. If you
take this sort of system engineering view, then you concern
yourself with the 90% rather than the 10%. Making sure the
system delivers business value is the important point.

As an example, I have seen a number of times a new system being
designed to replace an existing system. No one seems to
concentrate on the important point from the business's point of
view: When can you turn off the old system? Too often, the old
system and the new system are run in parallel and this costs the
company money. Planning for an early turnoff of the old system
whilst still maintaining acceptable service levels is the key
here, and it addresses directly the 90% of TCO.

This is what an architect should be focussing on, not on defining
elegant internal layering and other ueber-techie concerns.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

Hubert:

You've given a good example of this point. When I was in the U.S. Air Force,
I learned quite a bit about the "Hurry up and wait" philosophy, which
incidentally, may be a derivative of the "instant gratification" thing. I can't tell
you the number of times I've been forced to sit through seemingly endless
meetings in which some I.T. worthy drones on and on, giving the intended users a
litany of how great their system is going to be, with me wanting to stand up and
tell the users that there is absolutely no way Mr. I.T. can make these claims
with with any real certainty.

IMHO, the major contributors to post-deployment costs are comprised of
remedial work (those costs related to fixing problems that should have been detected
and fixed during the development process, or adding features that were
intended to have been in place at deployment), and enhancement/extension work
(adding features intended to satisfy requirements that were not known or foreseen
during development). The former is typically the result of simply running afoul
of the schedule, in terms of development cost (including the cost of change
orders) or time (as in, running out of it) to deployment. The latter is
typically reflective of the number and scope of the modifications to the system to
satisfy emerging requirements. Given that post-deployment remedial work is often
estimated to be 100 to 1000 times the cost of the same work during the
development process, some component of the post-deployment cost must be related to
the degree of difficulty of adding features. I suspect that a significant
portion of this last cost is due to the developers having designed an architecture
that is innocent of any knowledge regarding the true lifetime costs of complex
automated systems. That is, they simply do not understand the importance of
building maintainable and sustainable systems. Worse yet, in my nearly thirty
years of development experience, I have almost never had anyone, other than
myself, suggest that the anticipated lifetime costs of the system be assessed and
taken into account prior to the "closing the book" on the design of the
system. My point is that while predicting the future regarding the uses to be
addressed throughout the lifetime of a system might be impossible, designing a
system architecture that minimizes the effects of change is not, and even the
smallest design concession to maintainability and sustainability can pay huge
dividends throughout the lifetime of the system. If this is true, what factors are
present in the software development process employed today that seem to be
preventing these systems from being built? The statistics regarding lifetime
costs have not changed appreciably over the past several years, so what's the
deal? What factors can be identified that distinguish the low-maintenance systems
from others? Despite the flood of new and improved development tools that
enhance collaboration, communications, and productivity (and will probably
brighten our smiles and even reduce foot odor in the next release), post-deployment
costs remain stubbornly high. It has always seemed to me that focusing on
reducing development costs is looking through the wrong end of the telescope.

O.K., I'm stepping down off my soapbox. What do you guys think about this
syuff?

End of Rant <<

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Worse yet, in my nearly thirty years of development experience,
I have almost never had anyone, other than myself, suggest that
the anticipated lifetime costs of the system be assessed and
taken into account prior to the "closing the book" on the
design of the system.

I was working on a system a while back where I went to the data
centre people and asked what their requirements for running the
system would be. It turned out they had a long list of
requirements about clustering tools, logging tools, security,
etc, that no one had thought about at all. I got the data
centre's requirements tagged onto the end of the functional
requirements and asked the vendors how they intended to meet
those requirements. After all, a system is worse than useless -
i.e. it costs you a lot of money for no payback - if you can't
operate the system.

On another system, we were deciding which parts of the overall
business system could be implemented manually (rather than in
software) in order to meet the deployment deadline. Software
would reduce the running costs (cut out lots of temporary
labour), but the delay needed to write the software would cost
too much in terms of lost revenue. Those parts can be added
later after the initial deployment as a cost-reduction
initiative.

Pete, this soapbox ain't big enough for the two of us!

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Yuval Oren]

Hello all. I just joined this list. What a great discussion!



Pete wrote:



IMHO, the major contributors to post-deployment costs are comprised of
remedial work (those costs related to fixing problems that should have been
detected and fixed during the development process, or adding features that
were intended to have been in place at deployment), and
enhancement/extension work (adding features intended to satisfy requirements
that were not known or foreseen during development).



I think you have to examine each of these post-deployment costs
individually:



Fixing bugs not detected during development:



Sometimes this is a business decision; it may be a better move to release
your product now and fix the rest of the bugs in a later release. If this is
not the case, then it's probably of a sign of a deeper problem. Maybe the
test strategy is not sufficient, or maybe there's a fundamental design
problem that makes it more susceptible to problems. Test-driven development
is supposed to help this.



Adding features and enhancements after initial deployment:



Why is it more expensive to add these features in a second release? If
you're lucky enough to know *all* the requirements up front, then great, but
in my experience this is rare. So, one strategy is to try to minimize the
cost of deployment - automate more, etc. This is one of the key objectives
of agile processes, right?



I've also found in my experience that the development cost of adding
features is directly related to the "quality" of a design. In fact, I think
one way to measure the quality of a design is to see how much upheaval is
necessary to add unexpected features. I like to ask a lot of "what if you
needed to add this new feature"-type questions when evaluating a proposed
design. If you'll need to rewrite everything, that's probably a problem.
Incidentally, I've never been satisfied with how development methodologies
address the issue of promoting design quality. Does anyone have any thoughts
on this?





I suspect that a significant portion of this last cost is due to the
developers having designed an architecture that is innocent of any knowledge
regarding the true lifetime costs of complex automated systems. That is,
they simply do not understand the importance of building maintainable and
sustainable systems.



Yes. I believe it's possible to build a badly design system no matter what
methodology you use. I doubt there's a magic bullet here. I suppose your
hiring process has the greatest effect on this point. But, good
communication and all the other agile principles can't hurt.



I have almost never had anyone, other than myself, suggest that the
anticipated lifetime costs of the system be assessed and taken into account
prior to the "closing the book" on the design of the system.



I agree, and I believe it's often because the people who must maintain the
system are often not involved in setting the product priorities. Also,
everyone is under heavy time pressure to finish the project and doesn't
really care if it will cost more later. However, is this really a bad thing?
Aren't you more likely to correctly identify your maintenance issues after
deployment than trying to guess them pre-deployment? Why not just wait until
you start to feel the pain and then fix it?



-Yuval

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

There are other major post-deployment costs that are not so obvious, including:
- The cost of training people how to use the system properly.
- The cost of taking service calls to help people use the system properly or fix the problem created by using it improperly.
- The cost of integrating future systems with this one. (This includes the cost of the failure of some future projects because integration is too costly or unweildy, or not being able to justify starting some useful projects because of this problem).
- The opportunity costs of not being able to start an important project because this one has to be extended or remediated.

Steven Gordon

-----Original Message-----
From: Yuval Oren [mailto:***@qrs.com]
Sent: Sun 3/7/2004 8:20 PM
To: ***@topica.com
Cc:
Subject: RE: [AM] Article of Interest in CIO Magazine



Hello all. I just joined this list. What a great discussion!



Pete wrote:



IMHO, the major contributors to post-deployment costs are comprised of remedial work (those costs related to fixing problems that should have been detected and fixed during the development process, or adding features that were intended to have been in place at deployment), and enhancement/extension work (adding features intended to satisfy requirements that were not known or foreseen during development).



I think you have to examine each of these post-deployment costs individually:



Fixing bugs not detected during development:



Sometimes this is a business decision; it may be a better move to release your product now and fix the rest of the bugs in a later release. If this is not the case, then it’s probably of a sign of a deeper problem. Maybe the test strategy is not sufficient, or maybe there’s a fundamental design problem that makes it more susceptible to problems. Test-driven development is supposed to help this.



Adding features and enhancements after initial deployment:



Why is it more expensive to add these features in a second release? If you’re lucky enough to know *all* the requirements up front, then great, but in my experience this is rare. So, one strategy is to try to minimize the cost of deployment – automate more, etc. This is one of the key objectives of agile processes, right?



I’ve also found in my experience that the development cost of adding features is directly related to the “quality” of a design. In fact, I think one way to measure the quality of a design is to see how much upheaval is necessary to add unexpected features. I like to ask a lot of “what if you needed to add this new feature”-type questions when evaluating a proposed design. If you’ll need to rewrite everything, that’s probably a problem. Incidentally, I’ve never been satisfied with how development methodologies address the issue of promoting design quality. Does anyone have any thoughts on this?





I suspect that a significant portion of this last cost is due to the developers having designed an architecture that is innocent of any knowledge regarding the true lifetime costs of complex automated systems. That is, they simply do not understand the importance of building maintainable and sustainable systems.



Yes. I believe it’s possible to build a badly design system no matter what methodology you use. I doubt there’s a magic bullet here. I suppose your hiring process has the greatest effect on this point. But, good communication and all the other agile principles can’t hurt.



I have almost never had anyone, other than myself, suggest that the anticipated lifetime costs of the system be assessed and taken into account prior to the "closing the book" on the design of the system.



I agree, and I believe it’s often because the people who must maintain the system are often not involved in setting the product priorities. Also, everyone is under heavy time pressure to finish the project and doesn’t really care if it will cost more later. However, is this really a bad thing? Aren’t you more likely to correctly identify your maintenance issues after deployment than trying to guess them pre-deployment? Why not just wait until you start to feel the pain and then fix it?



-Yuval

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com


For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/7/2004 7:22:47 PM Pacific Standard Time, ***@qrs.com
writes:
Incidentally, I’ve never been satisfied with how development methodologies
address the issue of promoting design quality. Does anyone have any thoughts on
this?
Actually, that was one of the points I had intended to address in my post,
and I apologize for not explaining it more clearly or thoroughly. (I think I
just ran out of steam at the time!).

One of the "unclarities" I have regarding virtually all of the agile
methodologies pertains to system design, as in: "How do we build complex systems "in
the agile way" that are maintainable and sustainable, when we know up front
that we are looking at what might be a very small subset of the requirements
that the system might ultimately be called upon to satisfy?"

While the purists among us might suggest that we disregard those things that
are not known, because there is some likelihood that whatever work we do on
them may ultimately be unnecessary, and therefore a waste of resources, the
"impurists" might suggest that to do nothing in the face of seemingly
incontrovertible evidence that the system will require some level of post-deployment
maintenance or modification is irresponsible, derelict, or worse.

Now, 'fess up, boys: How many of you design systems in a manner that
facilitates post-deployment modification, even though this might not be strictly in
accordance with either the system requirements or the spirit of agility? I do! I
admit it! Go ahead, drag me down to the plaza in downtown Los Gatos, where
everyone will laugh at my clothes! (supposedly, the depths of Silicon Valley
ignominy).

Hey, I'm kidding, at least the part about Los Gatos. They don't actually
laugh, they smirk! (I'm told: this is second-hand hearsay). Actually, I suspect
that this is the point at which the immovable object meets the irresistible
force. (Hey, it's a phrase from my youth; stuff like that is in my genes!), In
this case, it's experience versus dogma.

I may be making too much of this, but it seems to come up often enough in
this forum (and others in which agile methodologies are diiscused). It is,
however, a topic that I've wondered about at times, and would appreiate the counsel
of the Elders on it.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Ian Chamberlain]

It is my belief that great design is something that cannot be taught.
You either have the ability or you don't. You can't learn to be a great
musician or artist. You can't learn to be a great architect or car
designer. You can never learn to be more than adequate. It is inherent
ability that sets aside the great from the adequate and I think this is
as true of software as any other field of endeavour that utilises
design.

Unfortunately it seems we have no surefire way of identifying great
software designers or great software designs. Most of IT, IME, find a
pattern that kind of works and stick with it, even in the face of
repeated identifiable weakness or failure. The vast majority of software
is built as quickly and cheaply as possible to do perform specific
functions at a specific point in time utilising specific technology.
Even if it did have a great design then, which would be pretty unusual,
it is simply not designed to be flexible and adaptable over time.

There are a number of ways we can look at this. It maybe that disposable
software is actually a good thing. Technology change is so fast that we
cannot hope to build software that is capable of adapting in a cost
effective manner over time and it actually is cheaper to just throw away
and start again. It maybe that the demand for business results and the
way people move around means that anything beyond a 2 year horizon just
isn't worth planning for. It could be that the effective costs and
benefits associated with software just are not well understood. It could
be that we have no idea how to build malleable software. It could be
that certain accepted best practices actually mitigate against adaptable
software because they enforce rigid structures.

Personally I think all of these play their part, and until some software
companies are prepared to really 'think outside the box' instead of just
mouth the words, nothing much will change.

Regards

Ian Chamberlain

-----Original Message-----
From: ***@aol.com [mailto:***@aol.com]
Sent: 08 March 2004 05:27
To: ***@topica.com
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/7/2004 7:22:47 PM Pacific Standard Time,
***@qrs.com writes:

Incidentally, I've never been satisfied with how development
methodologies address the issue of promoting design quality. Does anyone
have any thoughts on this?

Actually, that was one of the points I had intended to address in my
post, and I apologize for not explaining it more clearly or thoroughly.
(I think I just ran out of steam at the time!).

One of the "unclarities" I have regarding virtually all of the agile
methodologies pertains to system design, as in: "How do we build
complex systems "in the agile way" that are maintainable and
sustainable, when we know up front that we are looking at what might be
a very small subset of the requirements that the system might ultimately
be called upon to satisfy?"

While the purists among us might suggest that we disregard those things
that are not known, because there is some likelihood that whatever work
we do on them may ultimately be unnecessary, and therefore a waste of
resources, the "impurists" might suggest that to do nothing in the face
of seemingly incontrovertible evidence that the system will require some
level of post-deployment maintenance or modification is irresponsible,
derelict, or worse.

Now, 'fess up, boys: How many of you design systems in a manner that
facilitates post-deployment modification, even though this might not be
strictly in accordance with either the system requirements or the spirit
of agility? I do! I admit it! Go ahead, drag me down to the plaza in
downtown Los Gatos, where everyone will laugh at my clothes!
(supposedly, the depths of Silicon Valley ignominy).

Hey, I'm kidding, at least the part about Los Gatos. They don't actually
laugh, they smirk! (I'm told: this is second-hand hearsay). Actually, I
suspect that this is the point at which the immovable object meets the
irresistible force. (Hey, it's a phrase from my youth; stuff like that
is in my genes!), In this case, it's experience versus dogma.

I may be making too much of this, but it seems to come up often enough
in this forum (and others in which agile methodologies are diiscused).
It is, however, a topic that I've wondered about at times, and would
appreiate the counsel of the Elders on it.

Regards,

Pete
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/7/2004 8:25:30 PM Pacific Standard Time,
***@asu.edu writes:
There are other major post-deployment costs that are not so obvious,
Actually, Steven, I agree, and thank you for bringing them into the
discussion. I omitted them so as not to distract my focus from the effect of system
design on post-deployment costs. Now that you have brought them up, there could,
in fact, be a direct correlation between the design of a system and the costs
you've mentioned. But where in the agile equation does consideration for these
things fit?

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Post by p***@aol.com
In a message dated 3/7/2004 8:25:30 PM Pacific Standard Time,
There are other major post-deployment costs that are
not so obvious,
Actually, Steven, I agree, and thank you for bringing them into
the discussion. I omitted them so as not to distract my focus
from the effect of system design on post-deployment costs. Now
that you have brought them up, there could, in fact, be a
direct correlation between the design of a system and the costs
you've mentioned. But where in the agile equation does
consideration for these things fit?

It doesn't. Agile methods, like most software development
methods, focusses on the expensive pause at the beginning of the
project. No consideration of the bulk of the project is taken
into account. It is up to the business users to have the vision
of where the system is going and what it must do. Most of them
don't think like that, so guess what, you end up with failed
projects. The C3 project, XP's favourite story, was canned
because it wasn't delivering the business value required, as it
handled only 1/3 of the functionality and the old legacy system
couldn't be turned off.

Expecting users to work through the systemic implications of
development and operational tradeoffs is unrealistic. After all,
that's my job!

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[t***@poppendieck.com]

If an agile team practices lean
thinking, one of the fundamental tools
is to examine the value chain for the
business process the software plays in.
Focusing only on the software
development tasks will inevitably lead
to sub-optimization.

Tom Poppendieck
www.poppendieck.com
Author of Lean Software Development: An
Agile Toolkit


-----Original Message-----
From: Hubert Matthews
[mailto:***@oxyware.com]
Sent: Monday, March 08, 2004 4:36 AM
To: ***@topica.com
Subject: Re: [AM] Article of Interest in
CIO Magazine

Post by p***@aol.com
In a message dated 3/7/2004 8:25:30 PM

Pacific Standard Time,

Post by p***@aol.com
There are other major

post-deployment costs that are

Post by p***@aol.com
not so obvious,
Actually, Steven, I agree, and thank

you for bringing them into

Post by p***@aol.com
the discussion. I omitted them so as

not to distract my focus

Post by p***@aol.com
from the effect of system design on

post-deployment costs. Now

Post by p***@aol.com
that you have brought them up, there

could, in fact, be a

Post by p***@aol.com
direct correlation between the design

of a system and the costs

Post by p***@aol.com
you've mentioned. But where in the

agile equation does

Post by p***@aol.com
consideration for these things fit?

It doesn't. Agile methods, like most
software development
methods, focusses on the expensive pause
at the beginning of the
project. No consideration of the bulk
of the project is taken
into account. It is up to the business
users to have the vision
of where the system is going and what it
must do. Most of them
don't think like that, so guess what,
you end up with failed
projects. The C3 project, XP's
favourite story, was canned
because it wasn't delivering the
business value required, as it
handled only 1/3 of the functionality
and the old legacy system
couldn't be turned off.

Expecting users to work through the
systemic implications of
development and operational tradeoffs is
unrealistic. After all,
that's my job!

--
Hubert Matthews
http://www.oxyware.com/
Software Consultant
***@oxyware.com

For more information about AM, visit the
Agile Modeling Home Page at
www.agilemodeling.com
---------------------------

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

Is there a big difference between facilitating the implementation of next week's requirements and facilitating the implementation of next year's requirements?

-----Original Message-----
From: ***@aol.com [mailto:***@aol.com]
Sent: Sun 3/7/2004 10:26 PM
To: ***@topica.com
Cc:
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/7/2004 7:22:47 PM Pacific Standard Time, ***@qrs.com writes:

Incidentally, I’ve never been satisfied with how development methodologies address the issue of promoting design quality. Does anyone have any thoughts on this?

Actually, that was one of the points I had intended to address in my post, and I apologize for not explaining it more clearly or thoroughly. (I think I just ran out of steam at the time!).

One of the "unclarities" I have regarding virtually all of the agile methodologies pertains to system design, as in: "How do we build complex systems "in the agile way" that are maintainable and sustainable, when we know up front that we are looking at what might be a very small subset of the requirements that the system might ultimately be called upon to satisfy?"

While the purists among us might suggest that we disregard those things that are not known, because there is some likelihood that whatever work we do on them may ultimately be unnecessary, and therefore a waste of resources, the "impurists" might suggest that to do nothing in the face of seemingly incontrovertible evidence that the system will require some level of post-deployment maintenance or modification is irresponsible, derelict, or worse.

Now, 'fess up, boys: How many of you design systems in a manner that facilitates post-deployment modification, even though this might not be strictly in accordance with either the system requirements or the spirit of agility? I do! I admit it! Go ahead, drag me down to the plaza in downtown Los Gatos, where everyone will laugh at my clothes! (supposedly, the depths of Silicon Valley ignominy).

Hey, I'm kidding, at least the part about Los Gatos. They don't actually laugh, they smirk! (I'm told: this is second-hand hearsay). Actually, I suspect that this is the point at which the immovable object meets the irresistible force. (Hey, it's a phrase from my youth; stuff like that is in my genes!), In this case, it's experience versus dogma.

I may be making too much of this, but it seems to come up often enough in this forum (and others in which agile methodologies are diiscused). It is, however, a topic that I've wondered about at times, and would appreiate the counsel of the Elders on it.

Regards,

Pete


For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/7/2004 9:48:49 PM Pacific Standard Time,
***@asu.edu writes:
Is there a big difference between facilitating the implementation of next
week's requirements and facilitating the implementation of next year's
requirements?
Steven:

Objectively, no. My question is this (and if it turns out to be a
hair-splitter, I did not intend it to):

The Agile Manifesto has been criticized on occasion for being "mushy", or too
"touchy-feely", not enough substance, etc. How do you, and others in this
august group, address the issue of maintainability and sustainability within the
system design on occasions in which these considerations are not explicitly
part of the requirements?

Thanks in advance.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Post by p***@aol.com
In a message dated 3/7/2004 9:48:49 PM Pacific Standard Time,
Is there a big difference between facilitating the implementation of
next week's requirements and facilitating the implementation of next
year's requirements?
Objectively, no. My question is this (and if it turns out to be a
The Agile Manifesto has been criticized on occasion for being "mushy",
or too "touchy-feely", not enough substance, etc. How do you, and others
in this august group, address the issue of maintainability and
sustainability within the system design on occasions in which these
considerations are not explicitly part of the requirements?

I encourage my programmers to maintain the system in a good state of
(design) repair at all times, because that helps us add new more
features more quickly. It also has the side effect of keeping the system
easier to maintain, so we generally do not need to do anything extra
special to achieve maintainability. Since it is a side effect of Doing
Good Work, it happens free of charge.

The Agile Manifesto describes this specifically, although indirectly.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Yuval Oren]

Post by p***@aol.com
In a message dated 3/7/2004 8:25:30 PM Pacific Standard Time,
There are other major post-deployment costs that are not so obvious,
Actually, Steven, I agree, and thank you for bringing them into the

discussion. I omitted them so as not to distract my focus from the effect of
system design on post->deployment costs. Now that you have brought them up,
there could, in fact, be a direct correlation between the design of a system
and the costs you've mentioned. But >where in the agile equation does
consideration for these things fit?



One factor that needs to play into design is how much it will cost to
re-factor. If it's very easy to change some functionality - if it's hidden
in an implementation class, for example - then there's no need to build in
all the requirements or try to avoid future changes. If, however, it's
costly to change, such as a public interface or API, then you need to design
it to minimize future changes to the interface.

Post by p***@aol.com
While the purists among us might suggest that we disregard those things

that are not known, because there is some likelihood that whatever work we
do on them may >ultimately be unnecessary, and therefore a waste of
resources, the "impurists" might suggest that to do nothing in the face of
seemingly incontrovertible evidence that the >system will require some level
of post-deployment maintenance or modification is irresponsible, derelict,
or worse.



It also depends on how you define "known." If you know you'll need it, and
if you think it will be more difficult to add later, then you might as well
take care of it now. I feel that the deciding factor for these things should
be how much more costly it will be to add later rather than now, weight
against the chance you'll actually need it.



Another point to consider - and I'm sure the XP and AM folks will disagree
with me here - is the experience of your development team. If everybody
shares the "big picture," and they understand it well enough to make the
appropriate re-factoring correctly at the right time, then you should
consider yourself blessed for having such an aligned team. I've sometimes
found myself in cases, however, where it will take me less time to build the
extra feature than to explain how it should fit later. This is especially
relevant when you can't be there all the time. I've had consulting jobs
where I knew nobody would try to change the system until a year after I
left. I felt it appropriate in those situations to build up the software and
abstractions/layers so that it was very easy to add the anticipated upcoming
features.



-Yuval

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/7/2004 10:23:54 PM Pacific Standard Time, ***@qrs.com
writes:
It also depends on how you define “known.” If you know you’ll need it, and
if you think it will be more difficult to add later, then you might as well
take care of it now. I feel that the deciding factor for these things should be
how much more costly it will be to add later rather than now, weight against
the chance you’ll actually need it.
If it's true (statistically, at least) that an inordinately large portion of
the TCO is borne post-deployment, and some portion of the costs pertains to
remedial or enhancement work, does this constitute sufficient knowledge of
likely future events to warrant consideration in the design of the system, and if
so, how do these considerations fit within the agile "envelope", if they are
not explicit requirements?

Another point to consider –
and I’m sure the XP and AM folks will disagree with me here – is the
experience of your development team.
This might be the key. Like doctors, perhap we should 'first, do no harm",
which in this case might mean that we should apply our experience in the design
of the system to minimize post-deployment maintainability and sustainability,
as far as possible within reasonable development time and cost considerations.
How does this stand up?

I'm feeling better about this as we go along, so thanks very much to all.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 2:18:48 AM Pacific Standard Time,
***@oxyware.com writes:
Pete, this soapbox ain't big enough for the two of us!
I'm beginning to understand this whole thing, from a decision maker's
perspective, a whole lot more clearly now. There will be a short pause while I get
the ducks in order, so be ready to move over!

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 4:47:10 AM Pacific Standard Time,
***@rogers.com writes:
The Agile Manifesto describes this specifically, although indirectly.
As I thought. From a decision maker's perspecive, this can be a difficult gap
to bridge. It implies a reliance on the agile proponent to describe the agile
process and the potential benefits clearly, which could explain many of the
criticisms from its detractors. Thank you.

I like to think that I develop software with the same objectives as everyone
in this group, and it is somwhat often difficult to describe the agile process
and benefits in a way that satisfies the reluctance of potential clients to
employ it.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Post by p***@aol.com
In a message dated 3/8/2004 4:47:10 AM Pacific Standard Time,
The Agile Manifesto describes this specifically, although indirectly.
As I thought. From a decision maker's perspecive, this can be a
difficult gap to bridge. It implies a reliance on the agile proponent to
describe the agile process and the potential benefits clearly, which
could explain many of the criticisms from its detractors. Thank you.

I don't understand this: Agile has a problem because it has to be explained?

Post by p***@aol.com
I like to think that I develop software with the same objectives as
everyone in this group, and it is somwhat often difficult to describe
the agile process and benefits in a way that satisfies the reluctance of
potential clients to employ it.

But clients don't employ Agile programming techniques. Clients employ
programmers who might use Agile programming techniques. Clients employ
planning/requirements/communication techniques that may or may not be
Agile-minded. What would it take for clients to be clients and let
programmers be programmers?
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Post by p***@aol.com
I like to think that I develop software with the same
objectives as everyone in this group, and it is somwhat often
difficult to describe the agile process and benefits in a way
that satisfies the reluctance of potential clients to employ
it.

Agility has value when predicting the future is difficult or the
cost of being wrong (in terms of time or the liability for wrong
results) is low. In a predictable environment then converging on
a solution is slower than going straight to it. XP-style YAGNI
implies a very limited forward view, one story at a time.
Managers who are judged on long-term results find this difficult
to accept as it smacks of code-and-hack.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

Trying to directly address this problem in the technical and process domain generally creates a weight that impedes agility, adds costs, and masks the real underlying problem - communication and cooperation. The result is everyone's ass is covered, but solutions are still produced that are difficult to maintain, integrate, and adapt.

My understanding of the Agile Manifesto is that it advocates simplifying and emphasizing the lines of communication instead of trying to create process that ameliorates the need for communication by directly addressing the common symptoms of poor communication.

In other words, we should be communicating and learning with the people who will be using and maintaining the systems we build, not just the people paying for it and their subject matter experts. This communication should include eliciting the requirements necessary to make the system maintable, integratable, and adaptable. The communication with the people paying for the system should include making sure they understand these additional requirements sufficiently to properly prioritize them.

A process that has us guessing these additional requirements, their priorities, and then implementing them without this communication and cooperation is likely to miss the mark anyway.

Steven Gordon
http://sf.asu.edu

-----Original Message-----
From: ***@aol.com [mailto:***@aol.com]
Sent: Mon 3/8/2004 7:00 AM
To: ***@topica.com
Cc:
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/8/2004 4:47:10 AM Pacific Standard Time, ***@rogers.com writes:

The Agile Manifesto describes this specifically, although indirectly.

As I thought. From a decision maker's perspecive, this can be a difficult gap to bridge. It implies a reliance on the agile proponent to describe the agile process and the potential benefits clearly, which could explain many of the criticisms from its detractors. Thank you.

I like to think that I develop software with the same objectives as everyone in this group, and it is somwhat often difficult to describe the agile process and benefits in a way that satisfies the reluctance of potential clients to employ it.

Regards,

Pete
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com


For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 6:25:45 AM Pacific Standard Time,
***@rogers.com writes:
I don't understand this: Agile has a problem because it has to be explained?

Post by p***@aol.com
I like to think that I develop software with the same objectives as
everyone in this group, and it is somwhat often difficult to describe
the agile process and benefits in a way that satisfies the reluctance of
potential clients to employ it.

But clients don't employ Agile programming techniques. Clients employ
programmers who might use Agile programming techniques. Clients employ
planning/requirements/communication techniques that may or may not be
Agile-minded. What would it take for clients to be clients and let
programmers be programmers?
As far as I recall, there has not been a single time in my consulting
experience that a potential client has not inquired as to the major details of the
process to be employed, and these details play a significant role in their
decisions regarding vendor selection. (I'm referring primarily to business
applications here). If agile mehodologies were not the radical departure from
traditional development methodologies that they are perceived to be, and might provide
the substantial benefits with which they are credited, this might not be the
case. However, the rapidly increasing importance of software, and the
increasing reliance on software to facilitate virtually every facet of commerce, makes
the development methodology to be employed an important factor. Further,
while clients are still clients, and programmers are still programmers, the
reported benefits in productivity and quality that are purported to accrue when they
are combined in an agile manner substantially exceed those that accrue when
the relationship is based upon a more traditional model. Is it, in fact,
possible for clients and programmers to remain in their traditional roles and expect
the results of their union to be any different than they have been in the
past thirty-some years? If it is, what benefits do the agile methodologies bring
to the table? If the potential paths from start to finish of a development
project are visualized as a triangle (ABC), agile methodologies are perceived to
provide a way to go straight from A to C, without taking the longer path
through B (relative to the development of "working software", not distance).

BTW, my postings in this thead are intended to elicit comments from agile
practitoners more experenced that I that might serve to answer some of the
criticisms that have been posted in this forum and elsewhere regarding the benefits
of the agile methodologies and the issues to which they pertain. It is clear
from these postings that some clarity would be both welcome and useful. No
offense is intended.

Comments/Opinions/Enlightenment, please.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

***@aol.com wrote:

<snip />

Post by p***@aol.com
However, the rapidly increasing importance of software, and the
increasing reliance on software to facilitate virtually every facet of
commerce, makes the development methodology to be employed an important
factor.

Of course it is important, but only secondarily. What matters is whether
the client gets what they need when they need it. If a client uses the
development methodology as an important factor in deciding on a vendor,
then the client is looking in the wrong place. I understand that they
may have been trained to look there, but nevertheless it is the wrong
place. This is Management 101: you get what you measure. Does the client
want software? or a software process? My clients, so far, have wanted
software.

Post by p***@aol.com
Further, while clients are still clients, and programmers are
still programmers, the reported benefits in productivity and quality
that are purported to accrue when they are combined in an agile manner
substantially exceed those that accrue when the relationship is based
upon a more traditional model. Is it, in fact, possible for clients and
programmers to remain in their traditional roles and expect the results
of their union to be any different than they have been in the past
thirty-some years? If it is, what benefits do the agile methodologies
bring to the table? If the potential paths from start to finish of a
development project are visualized as a triangle (ABC), agile
methodologies are perceived to provide a way to go straight from A to C,
without taking the longer path through B (relative to the development of
"working software", not distance).

I don't understand any of this. To seem to think that I am a
traditionalist or something. I am not; I am an Agile practitioner and
have been for a few years.

You may have miscontstrued my comment. Clients should make business
decisions; programmers should make programming decisions. How the
programmers build software is a programming decision. The client and the
programmers ought to agree on the level of communication they can
sustain throughout the project, and the programmers have to work within
that framework. It is certainly not my goal to see clients and
programmers continue /not/ to talk to one another, as tends to happen
with more traditional approaches.

Post by p***@aol.com
BTW, my postings in this thead are intended to elicit comments from
agile practitoners more experenced that I that might serve to answer
some of the criticisms that have been posted in this forum and elsewhere
regarding the benefits of the agile methodologies and the issues to
which they pertain. It is clear from these postings that some clarity
would be both welcome and useful. No offense is intended.

More experienced than what?
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 6:50:26 AM Pacific Standard Time,
***@asu.edu writes:
A process that has us guessing these additional requirements, their
priorities, and then implementing them without this communication and cooperation is
likely to miss the mark anyway.
Steven:

Thank you for answering the qustion that I am preparing to post. We seem to
be of one mind regarding the objectives of the agile methodologies, but IMHO,
there is a great deal of misinformation regarding them that is clouding these
issues that needs to be clarified.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Gaythorpe, Dagna]

Post by Michael Vizdos
-----Original Message-----

Post by p***@aol.com
I like to think that I develop software with the same objectives as
everyone in this group, and it is somwhat often difficult

to describe

Post by p***@aol.com
the agile process and benefits in a way that satisfies the

reluctance of

Post by p***@aol.com
potential clients to employ it.

But clients don't employ Agile programming techniques. Clients employ
programmers who might use Agile programming techniques.
Clients employ
planning/requirements/communication techniques that may or may not be
Agile-minded. What would it take for clients to be clients and let
programmers be programmers?

I think the rot started with the PC - then clients (and managers, users, and
so on) began to assume that they knew about IT, because they had a PC on
their desk (or their child was doing all sorts of clever stuff at home), and
how hard could it be? </cynicism>

In the <censored - I'm not *that* old, am I?> years I have been gracing this
wonderful profession <g>, I keep meeting the same view from the users (with
the exception of one company, my very first junior programmer job, that had
a fully integrated application suite. No interfaces, no data re-entry,
instant update to everyone who needed it. Written in a FORTRAN based
language, running on Prime (anyone else remember them?) The 'Integration'
soapbox is calling...). That IT is a problem, a burden, and an obstacle to
getting their jobs done.

The users don't trust us - in-house IT is regarded as a drain on their
resources, and consultants are worse. They know that the enterprise can't
live without IT, it just isn't feasible to employ that many clerks these
days (and they couldn't keep track of phone calls or electricity consumption
or bills issued and paid manually any more), and they think that we have
them over a barrel. And they have been to way too many presentations about
the latest, greatest silver bullet - sometime, on a crowded commuter train,
get up and shout 'BPR' and see how many people dive under their seats...

The users, clients, business, whatever we want to call them, have
experienced too much pain where it hurts them most (in money, and in effort
expended to run the business), and so they are not inclined to take our word
for anything without a clear understanding of what we are suggesting, how we
intend to do it, how it is better than the way they have done it so far, and
what the chances of failure are. And failure includes all sorts of stuff now
- like not reducing their pain enough, or failing to get the whole of the
legacy system turned off, or taking too long and not delivering as much as
they thought we meant (not just what we said). They also want reassurance
that they (personally) will get more out of it that they have to put in.

So, when we go in and suggest doing something new (Agile Modelling, XP,
Enterprise Architecture, migrate to Linux), we are regarded with all the
trust of a child for a smiling dentist. They remember all the times we
assured them that it wouldn't hurt a bit.

Which boils down to: the problem isn't with explaining the Agile approach -
it is with winning the trust of the clients. And it isn't a problem for the
Agile community - it is a problem for everyone who works in IT.

Heading back behind my parapet now (it has been a bit busy here lately),

Dagna

Dagna Gaythorpe
Data Architect
International IT

Post by Michael Vizdos
tttt COLT TELECOM GROUP PLC
Beaufort House, 15 St Botolph Street,
London EC3A 7QN

t (+ 44) 020 7 390 7896
f (+ 44) 020 7 947 1176
e ***@colt-telecom.com


*************************************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Beaufort House, 15 St. Botolph Street, London, EC3A 7QN
Tel. [phone]


This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message. Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.
*************************************************************************************

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

-----Original Message-----
From: Gaythorpe, Dagna [mailto:***@colt-telecom.com]
Sent: Mon 3/8/2004 10:02 AM
To: '***@topica.com'
Cc:
Subject: RE: [AM] Article of Interest in CIO Magazine

I think the rot started with the PC - then clients (and managers, users, and so on) began to assume that they knew about IT, because they had a PC on their desk (or their child was doing all sorts of clever stuff at home), and how hard could it be? </cynicism>

Dagna,

I am happy to see the end of your cynicism, but the lack of a <cynicism> tag makes me wonder how long ago your cynicism began. :-)

One way to try to get past the trust issue is to guarantee that from iteration 2 on we will deliver greater value than we cost, and that they can cancel after any iteration and keep what we have delivered so far. And then deliver. So far, I have not found a client that would prefer to go back to the old way of having their project 90% done for 90% of the duration of the project.


For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 9:04:49 AM Pacific Standard Time,
***@colt-telecom.com writes:
think the rot started with the PC - then clients (and managers, users, and so
on) began to assume that they knew about IT, because they had a PC on their
desk (or their child was doing all sorts of clever stuff at home), and how hard
could it be? </cynicism>
In the <censored - I'm not *that* old, am I?> years I have been gracing this
wonderful...
It might be difficult for software developers and users to foresee the
future, but apparently some have no difficulty in reading minds. My thoughts
regarding the issues you've brought up are similar to yours.

Also, Prime Computers running Primos is on my resume, as is Pick Systems
experience.

Thanks,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 8:04:26 AM Pacific Standard Time,
***@hotmail.com writes:
Personally I think all of these play their part, and until some software
companies are prepared to really 'think outside the box' instead of just mouth the
words, nothing much will change.
Ian:

I agree with what you've posted. I do, however, think that there is a way to
improve the situation substantially (although I have not yet been able to
demonstrate any discernible positive results). I sometimes give in to the notion
that I'm simply engaging in "wishful thinking", but those successes I've had,
I've tried to learn from and build on (along with the failures, of course,
since they are often the best lessons).

Thanks, and regards.

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 2:36:18 AM Pacific Standard Time,
***@oxyware.com writes:
It is up to the business users to have the vision
of where the system is going and what it must do. Most of them
don't think like that, so guess what, you end up with failed
projects.
Hubert:

This is where I came in, so let me get this lined up properly.

(1) it is difficult or impossible for the development team (including user
managers and stakeholders collaborating closely and continuously) to predict the
future with any degree of certainty regarding the ultimate requirements of
the system under construction (a given).

(2) the agile methodologies are primarily concerned with that "expensive
pause" at the front end of the development process, and therefore less concerned
with that substantially more expensive post-deployment period (which may not be
possible anyway).

(3) much of the overall cost of the system is borne post-deployment, beyond
the primary scope of the agile methodologies.

(4) the business value that can be achieved through agility might be
extremely difficult to demonstrate and/or estimate at the front end.

(5) User communities have been conditioned to more or less expect disasters
(as in "The darn thing took too long and cost too much to build, and it didn't
work the way we expected it to when it was delivered, and they've been fixing
it for the last X years and it still isn't right!"), so their reluctance to
engage in a new and unproven development methodology is entirely understandable.

This is essentially a compilation of comments from members of this forum
regarding this topic over the past few months. I may ave missed a few, but this
should be close to what I've been reading/hearing. Have I gotten it right so
far? If so, I'd sure appreciate some guidance from the group regarding where we
go from here as an industry. I have no doubt that agile methodologies currently
provide an effective development strategy for many applications, but there
seems to be no dearth of criticism, even from some who have tried it. (as in,
"damning with faint praise", in many cases).

In a lighter vein, perhaps the spread of agile methodologies into the
mainstream will be analogous to the reports of a young lady who had been married
three times, but had yet to consummate any of them. Apparently her first husband
was an old family retainer, a partner in her father's business. He was
forty-five years her senior, and doted on her. After reciting their vows, as they were
leaving the church, he collapsed and died of a heart attack.

After several years of grieving, she again ventured out and made the
acquaintance of the son of a business acquaintance, a sharp young lad of Italian
descent, given to a life of leisure, the scion of an well-known and affluent local
family. On the day of their wedding, after reciting their vows, he was killed
in a hail of gunfire on the church steps, the result of a Mafia "Turf War"
between his father and the head of another family.

Again, after a suitable period, she found herself a stalwart young man, with
a flourishing career in the sale of large-scale mainframe computer systems.
The company he worked for was IBM, and all he wanted to do was tell her how
great things would be when it finally got there.

My apologies to the faint of heart, no offense intended. I'm sure that there
are many of you who fully and completely understand the object of this story.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Post by p***@aol.com
(3) much of the overall cost of the system is borne
post-deployment, beyond the primary scope of the agile
methodologies.

Agility is good for responding to changes both during and after
the initial development. What needs to be considered is the
overall costs of the system compared to the benefits, whilst
taking into account the value of the choice points along the way
(real options). The field that considers such tradeoffs is
called systems engineering and is not widely enough studied or
applied.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 1:23:47 PM Pacific Standard Time,
***@oxyware.com writes:
The field that considers such tradeoffs is
called systems engineering and is not widely enough studied or
applied.
Hubert:

I have spent most of my career trying to make this point. Too often, systems
are built under too much pressure to "deliver the goods" as rapidly as
possible, using a process that will not support that sort of effort. If this is to be
the way software is built, some effort must be put into finding a design
(i.e., engineering a system) that minimizes the difficulties in achieving
reasonable maintainability and sustainability.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

I think possibly Hubert was referring to "systems as opposed to software",
in the sense that the code we write is just a small part of the overall
solution to a business problem. In the end - if we're lucky - people use our
code to do *stuff*, and that *stuff* is more important than the code we
wrote that they use to do it :-)

Jason


_____

From: ***@aol.com [mailto:***@aol.com]
Sent: 08 March 2004 21:45
To: ***@topica.com
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/8/2004 1:23:47 PM Pacific Standard Time,
***@oxyware.com writes:

The field that considers such tradeoffs is
called systems engineering and is not widely enough studied or
applied.

Hubert:

I have spent most of my career trying to make this point. Too often, systems
are built under too much pressure to "deliver the goods" as rapidly as
possible, using a process that will not support that sort of effort. If this
is to be the way software is built, some effort must be put into finding a
design (i.e., engineering a system) that minimizes the difficulties in
achieving reasonable maintainability and sustainability.

Regards,

Pete
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Post by Jason Gorman
I think possibly Hubert was referring to "systems as opposed to
software", in the sense that the code we write is just a small
part of the overall solution to a business problem. In the end
- if we're lucky - people use our code to do *stuff*, and that
*stuff* is more important than the code we wrote that they use
to do it :-)

Indeed. I have found that business systems that use software
often fail not because of the software but because of the amount
of business-process change required. It is much easier to change
software than it is to get users to change their habits. The
"release often" approach of agile methods is a far cry from
getting something into production. Consider what happens when
you have a few thousand users at 311 sites in 120 countries using
different languages. Rolling out something to them is a major
effort, and a lot more than putting some files on a server
somewhere.

As Jason points out, *stuff* is what businesses want and pay
for. Software is just a part of it.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

I suspect that the field called "Systems Engineering" is not the only approach that considers such tradeoffs. I also suspect "Systems Engineering" does a lot more than just consider such tradeoffs.

I suspect that applying even a Systems Engineering approach will not be much more successful than what we do now without sufficient communication and cooperation between all the concerned parties.

Steven Gordon
http://sf.asu.edu/


_____

From: ***@aol.com [mailto:***@aol.com]
Sent: 08 March 2004 21:45
To: ***@topica.com
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/8/2004 1:23:47 PM Pacific Standard Time, ***@oxyware.com writes:

The field that considers such tradeoffs is
called systems engineering and is not widely enough studied or
applied.

Hubert:

I have spent most of my career trying to make this point. Too often, systems are built under too much pressure to "deliver the goods" as rapidly as possible, using a process that will not support that sort of effort. If this is to be the way software is built, some effort must be put into finding a design (i.e., engineering a system) that minimizes the difficulties in achieving reasonable maintainability and sustainability.

Regards,

Pete
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com


For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Pete)

Post by p***@aol.com
(3) much of the overall cost of the system is borne post-
deployment, beyond the primary scope of the agile
methodologies.

I guess it's too early to get figures on how systems built to
agile approaches fare in comparison. We have recently
heard (unless I'm getting mu forums confused) how the
traditional fixed price bidding gets the winner of the
tender loads of money - not off the original contract which
is a loss, but off all the change requests that come in
after the requirements are signed off.

Where this is the case, it is hardly surprising that the majority
of the cost occurs after initial delivery.

Of course, there will be other factors to take into account,
such as the first feedback from the users that doesn't come
until after first delivery, whereupon they get their first
opportunity to say why the system is no use to them...

I'm sure much of the overall cost of the system will still be
after deployment, specially if first deployment is 4 weeks into
a six month project.

In short, the figures may no longer hold true, but it is too
early to tell.

(Hmm - release early, so the total cost will be a lot less...
there's an argument to try, when persuading customers.
Let me know if it works ;-) )


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 12:49:11 PM Pacific Standard Time,
***@rogers.com writes:
I don't understand any of this. To seem to think that I am a
traditionalist or something. I am not; I am an Agile practitioner and
have been for a few years.
In viw of the cogent and well-thought-out comments that you have contributed
to this forum in the past, what would give you impression that i considered
you a "traditionalist"? If that's the message you took from my post, I
apologize. I intended no offense. My references were not directed at you, they were
descriptive of some of the experiences I have had with potential clients, many of
whom have been burned often enough in the past to want chapter and verse
about how their software is going to be built. If your experiences are different,
consider yourself extremely fortunate. Descriptions of experiences lsimilar to
mine have appeared in quite a few forums, so others have apparently found
this to be a problem at least worthy of note as well.

Regarding your question about the level of experience to which I was
referring, the answer is: More experienced than I. (The reference to this in my post
should have read "from
agile practitoners more experenced than I, that..."). In fact, relative you
and to most of the other participants in this forum, I am pretty much a
beginner, still learning something new from just about every post I receive.

IMHO, at least here in Silicon Valley (where just about everyone is an expert
in software development, or at least thinks they are), things might be a
little different from the way they are where you hang your hat. It is not unusual,
for example, to go to a potential client for what is supposed to be a brief
presentation, and find a roomful of specialists (Strength in numbers? Nothing
better to do with their time? Hanging aound until lunch arrives?), all wanting
to get right to a demo, after which the merits of one approach or another are
debated ad nauseum. Of course, each one of them believes that their approach
is substantially superior to ours, and each one just happens to feature their
particular specialty as the only way the desired solution may be achieved. Of
course, if they were able to deliver a solution as simply, easily and quickly
as they describe, why are they not doing it?

Something to think about...Again, my apologies for any offense.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Post by p***@aol.com
In a message dated 3/8/2004 12:49:11 PM Pacific Standard Time,
I don't understand any of this. To seem to think that I am a
traditionalist or something. I am not; I am an Agile practitioner and
have been for a few years.
In viw of the cogent and well-thought-out comments that you have
contributed to this forum in the past, what would give you impression
that i considered you a "traditionalist"?

It was the only way I could understand the comments you'd made. I didn't
know whether you'd simply misconstrued things I'd written earlier.

Post by p***@aol.com
If that's the message you took
from my post, I apologize. I intended no offense.

I would say more confusion than offence.

Post by p***@aol.com
Of course, if they were able to deliver a solution as simply,
easily and quickly as they describe, why are they not doing it?

Right. My most recent experiences have been unusually good: I have
described my approach essentially like so --

1. Every two weeks we're going to decide what to do for the next two
weeks, based on what's important to you, how quickly we're going and
whether we got right what you have asked for so far.
2. You are responsible for deciding what we build, although we'll help
as much as you want with that.
3. We are responsible for telling you how long it's going to take and
you can use that to decide priorities.
4. The more you participate, the better the product will be.
5. At the end of any two-week period, if you don't like the way things
are going, then please fire me/us.

I'm not afraid to walk away from prospective clients who can't
understand these simple principles. I admit that that is not a common
situation for people -- and yes, at some point, I'm going to have to
"cave in," but that's just an issue of being a good businessman: if you
don't have multiple income streams and a reasonable pile of cash in the
bank, then you don't have options.

I should mention that most of my clients /really/ like point #5. It has
taken me a long time to learn how to phrase that well, and in its
current incarnation, it elicits a very positive response.

Take care.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 1:58:48 PM Pacific Standard Time,
***@objectmonkey.com writes:
I think possibly Hubert was referring to "systems as opposed to software", in
the sense that the code we write is just a small part of the overall solution
to a business problem. In the end - if we're lucky - people use our code to
do *stuff*, and that *stuff* is more important than the code we wrote that they
use to do it :-)
Jason:

Thanks very much for the clarification. I may have been on too much of a roll
to see that.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 2:06:00 PM Pacific Standard Time,
***@asu.edu writes:
I suspect that applying even a Systems Engineering approach will not be much
more successful than what we do now without sufficient communication and
cooperation between all the concerned parties.
Amen!

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/8/2004 9:30:41 PM Pacific Standard Time,
***@poppendieck.com writes:
Focusing only on the software
development tasks will inevitably lead
to sub-optimization.
Hey, it looks like the stars are out early tonight!

Thanks for your thoughts, and thanks for your book.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 3/9/2004 12:00:24 PM Pacific Standard Time,
***@rogers.com writes:
I should mention that most of my clients /really/ like point #5. It has
taken me a long time to learn how to phrase that well, and in its
current incarnation, it elicits a very positive response.
That sounds good to me. A good list, too. I've used that #5 approach myself
on occasion, whn it was warranted by the situation: desoite our delivering
exactly what he wanted, he continued to complain bout the slow pace (which he was
setting). That's when I popped he big one, and asanticipated, he backed down.
From then on, the projct was a dream.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------