Discussion:
[AM] Problems ever occur in Agile?
SChing Chan
2004-03-29 15:26:23 UTC
Permalink
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWnbtka/ Ivo Interactive
===========================================================

Hi All,

I just want to carry out a small survey on checking out whether how
often problems occur in any stage when using Agile. Hope I can get as
many response as possible.

Qns: How often problems occurred in:

i) Concept Phase:
The needs for the software system are determined and the basic concept
of the software system evolves.

less often to most often
1 2 3 4 5

Example?

ii) Requirements Phase:
First formal mandatory phase of software development that provides a
detailed description of the software system to be developed.

less often to most often
1 2 3 4 5

Example?

iii) Design Phase:
The requirements are analyzed and the method of implementation is
determined.

less often to most often
1 2 3 4 5

Example?

iv) Implementation Phase:
Development of the software code modules and initial unit tests are
performed.

less often to most often
1 2 3 4 5

Example?

v) Integration and Test Phase:
Combine modules into a single system and test the functionality of the
system.

less often to most often
1 2 3 4 5

Example?

vi) Maintenance Phase:
Repair or replacement of failed components, and preventive maintenance
may require the servicing of components to prevent deterioration.

less often to most often
1 2 3 4 5

Example?

Thanks All!

Regards,
SChing

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Steven Gordon
2004-03-29 15:40:02 UTC
Permalink
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

Agile software development is a holistic approach that does not have these discrete phases. So, I guess my answer is I do not have any problems with these phases as more.

-----Original Message-----
From: SChing Chan [mailto:***@yahoo.com]
Sent: Mon 3/29/2004 8:26 AM
To: ***@topica.com
Cc:
Subject: [AM] Problems ever occur in Agile?



===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAbWlcrsa/ Ivo Interactive
===========================================================

Hi All,

I just want to carry out a small survey on checking out whether how
often problems occur in any stage when using Agile. Hope I can get as
many response as possible.

Qns: How often problems occurred in:

i) Concept Phase:
The needs for the software system are determined and the basic concept
of the software system evolves.

less often to most often
1 2 3 4 5

Example?

ii) Requirements Phase:
First formal mandatory phase of software development that provides a
detailed description of the software system to be developed.

less often to most often
1 2 3 4 5

Example?

iii) Design Phase:
The requirements are analyzed and the method of implementation is
determined.

less often to most often
1 2 3 4 5

Example?

iv) Implementation Phase:
Development of the software code modules and initial unit tests are
performed.

less often to most often
1 2 3 4 5

Example?

v) Integration and Test Phase:
Combine modules into a single system and test the functionality of the
system.

less often to most often
1 2 3 4 5

Example?

vi) Maintenance Phase:
Repair or replacement of failed components, and preventive maintenance
may require the servicing of components to prevent deterioration.

less often to most often
1 2 3 4 5

Example?

Thanks All!

Regards,
SChing

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWlcrsf/ Lorillard
===========================================================

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




===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Rick Lutowski
2004-03-30 01:20:21 UTC
Permalink
===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtka/ Ivo Interactive
===========================================================
Post by SChing Chan
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAb7APIWa/ Crazy Aaron Enterprises
===========================================================
Agile software development is a holistic approach that does not have these discrete phases. So, I guess my answer is I do not have any problems with these phases as more.
Phases are an integral part of formal methodologies because
of the problem these methodologies address. Recall that
the earliest methodologies were from the gov't sector,
notably DoD. I was a DoD (Navy) civil servant for 10 years
much of it in the software development area. The following
are based on my recollections:

Management of DoD software projects has always presented
special difficulties because of the nature of the contracting
rules set by Congress. The problem in a nutshell is that
gov't contracting agency employees are prohibited by law
from "managing" the employees of a contractor. A gov't
contracting agency worker cannot tell or suggest (give the
appearance of telling) a contractor employee what to do.
That is the job of contractor management. Severe disciplinary
action can be taken against gov't employees who break this
rule. (They also cannot buy one another gifts, and a lot
of similar restrictions.)

Of course, the gov't contracting agency must have some means
of directing and monitoring the action of the contractor.
As we all know, this need is especially acute in the case
of software development. Given the constraints imposed
by Congress in their infinite wisdom (civil servants use a
number of such euphemisms to make their life more tolerable).
what is the gov't agency to do?

This is the _management_ problem that the infamous waterfall
and other formal methodologies are intended to help solve.

Which brings us to phases.

Phases are time periods during which certain tasks take
place. In DoD and other gov't methodologies, they end
with a formal review in which documents are presented to,
and reviewed by, the contracting agency. Usually there
are also meetings and presentations in which the employees
of both sides are able to get in some face-to-face without
undue fear of being hauled on the carpet for breaking
contracting laws. The contracting agency can approve or
disapprove the work up to that point by approving or
disapproving the documents. The documents thus serve as
a kind of "intermediary" that allow the contracting
agency to direct the work of the contractor without
violating, or appearing to violate, the contracting laws.

So waterfall and other formal, document-driven methodologies
are not inherently bad. Instead, they are "best we can
do" solutions to an inherently bad situation imposed from
above. In actual practice, contracting agencies typically
do whatever they have to do to get the job done, and the
methodologies serve more of a "check the box" function,
which hopefully keeps contracting layers off everbody's
back. Other than that, the are often ignored by the
contractor working level, so their impact on the actual
development is not as severe as might be imagined. This
is why some software developed for the gov't actually
works.

What is bad is when managers in industry or other
organizations not subject to gov't contracting laws
(Federal, state, or local) pick up these methodologies
and use them in place of more efficient management
mechanisms that are NOT prohibited to them as they are
to gov't agencies. You can quess as well as I all the
reasons why private sector managers might do this.

So the first message here is that the holistic agile
approach will not work on gov't projects. If you tried
it, somebody would likely wind up getting fired, or
worse, for breaking the contracting laws.

The second message is to cut formal methodologies a
little slack, at least in the gov't sectors. If it
really bothers you, write your elected officials a
letter and tell them how harmful their contracting
laws are. (But don't expect anything to happen
because they have heard it all before. Congress fancies
itself guided by higher ideals such as "fairness".)

One more thing about phases.

In addition to providing a convenient point of control
for gov't contracting agencies, they can also serve as
convenient descriptive mechanisms for ANY software
development methodology. When used in this way, the
business about ending them with formal reviews of
documents is usually dispensed with. Freedom uses
phases for such descriptive purposes. When methodologies
such as Freedom talk about phases, it should not be
taken to imply that a waterfall must be followed, or
formal reviews must be held, or that the phases cannot
overlap in time, i.e., requirements, design and coding
cannot proceed in parallel. In these methodologies,
phases provide a convenient modularization function
for descriptive purposes. If someone were to fully
automate the methodology at some point, the phases then
might become objects or classes or packages. Nothing
would necessarily precludes them from executing in
parallel (unless maybe it was for a gov't project.)

So the third message is that, for methodologies like
Freedom that use phases for descriptive rather than
management control purposes, phases and agile's
holistic approach are _not_ mutually exclusive.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Brad Appleton
2004-03-30 06:52:21 UTC
Permalink
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================
Post by Rick Lutowski
So the first message here is that the holistic agile
approach will not work on gov't projects. If you tried
it, somebody would likely wind up getting fired, or
worse, for breaking the contracting laws.
Interesting - I wonder what the folks at AgileTek did to XP to create their Agile+ methodology (formerly CodeScience from Geneer) where they claim to have successfully used it many times on large systems and government contracts. See www.agiletek.com for details. One of Agile+ creators is John Manzo, who has a history of leading successful large-scale gov't/military software development, and was (is?) on the Arlie Software Council.
--
Brad Appleton <***@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Rick Lutowski
2004-03-30 17:35:41 UTC
Permalink
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtka/ Lorillard
===========================================================
Post by Brad Appleton
Interesting - I wonder what the folks at AgileTek did to XP to create their Agile+ methodology (formerly CodeScience from Geneer) where they claim to have successfully used it many times on large systems and government contracts. See www.agiletek.com for details. One of Agile+ creators is John Manzo, who has a history of leading successful large-scale gov't/military software development, and was (is?) on the Arlie Software Council.
Those were my observations from having worked in the trenches.
I am not a contracting legal officer, so do not know all the
possible variances. I do know that contractng law is complex.

I think a lot depends on the specific contracting situation:
sole source versus competitive, single versus multi-contractor,
etc. Even more depends on the personality of the contracting
officer -- whether he is a 'stickler for regs', is willing to
bend the rules (whatever they are), etc. I have seen gov't
projects run many different ways. Also, when development
occurs totally within a gov't agency, they can do whatever
they want as contracting rules do not apply. So there are indeed
situations where agile could be applied to gov't projects.
But not all gov't projects.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Philippe Back (High Octane)
2004-03-31 07:18:28 UTC
Permalink
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

Rick,

Why is there written "*Alligator* Cockburn" in your Slugout paper ?
Shouldn't it be Alistair ?

BTW, I read the whole set about freedom at jreality and it makes a lot of
sense.
I do not agree on using only tables for structures etc. UML (or whatever)
diagrams make a lot of sense for me (I am pretty visual). But with a good
tool, both versions can exist.

The good thing I see there is that there is enough info to get things done
(aligned w/ Parnas's paper on faking a rational process) without getting
overwhelmed.

IMV, when someone has reached some level of understanding in methodology, I
guess simplification is in order. Freedom provides that.

/Philippe Back
www.highoctane.be

----- Original Message -----
From: "Rick Lutowski" <***@jreality.com>
To: <***@topica.com>
Sent: Tuesday, 30 March, 2004 19:35
Subject: RE: [AM-Old List] [AM] Problems ever occur in Agile?


This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbVZCKia/ Lorillard
===========================================================
Post by Brad Appleton
Interesting - I wonder what the folks at AgileTek did to XP to create
their Agile+ methodology (formerly CodeScience from Geneer) where they claim
to have successfully used it many times on large systems and government
contracts. See www.agiletek.com for details. One of Agile+ creators is John
Manzo, who has a history of leading successful large-scale gov't/military
software development, and was (is?) on the Arlie Software Council.


Those were my observations from having worked in the trenches.
I am not a contracting legal officer, so do not know all the
possible variances. I do know that contractng law is complex.

I think a lot depends on the specific contracting situation:
sole source versus competitive, single versus multi-contractor,
etc. Even more depends on the personality of the contracting
officer -- whether he is a 'stickler for regs', is willing to
bend the rules (whatever they are), etc. I have seen gov't
projects run many different ways. Also, when development
occurs totally within a gov't agency, they can do whatever
they want as contracting rules do not apply. So there are indeed
situations where agile could be applied to gov't projects.
But not all gov't projects.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbVZCKif/ Crazy Aaron Enterprises
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Rick Lutowski
2004-03-31 18:07:09 UTC
Permalink
This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
===========================================================
MORTGAGE / REFINANCE RATES ARE LOW. ACT NOW!
3 Mortgage brokers compete for your business.
Great rates, no obligation, and easy form.
http://click.topica.com/caabZulbUrKDAbWnbtka/ Insurance4usa.com
===========================================================
Post by Philippe Back (High Octane)
Why is there written "*Alligator* Cockburn" in your Slugout paper ?
Shouldn't it be Alistair ?
Oops! Must be a Freudian slip (used to live in Florida).
Will look into it. Thanks.
Post by Philippe Back (High Octane)
BTW, I read the whole set about freedom at jreality and it makes a lot of
sense.
Thanks for the observation.

Freedom _is_ very straightforward, even simple, once one
understands it. It is the minimum, or at least strives to
be the minimum, needed to do a good job. (Isn't that an
agile principle?)

Freedom's minimalist approach demonstrates that software
engineering need not be nearly as complex as many
methodologies would have us believe. While the 'devils
in the details' remain, the essence of software engineering
is not as difficult as previously thought when the problem
is viewed from the perspective of Freedom.

This line of thought leads straight to Brooks and his famous
"No Silver Bullet" paper. Brooks pointed out that the essence
of software engineering (and by essence, he meant the
requirements) was where the actual difficulties reside,
and that 'no silver bullet' could ever be found until the
problems of the essence were solved. Based on having used
Freedom for a number of years, I believe Freedom is a major
step in helping solve the problems of the essence. If others
validate this observation -- which cannot happen until
others learn Freedom and apply it -- then Freedom may
ultimately result in creation of a software engineering silver
bullet, as defined by Brooks. (Note that Brooks clearly defined
the term 'silver bullet' as an attainable goal. Many use the
term 'no silver bullet' as synonymous with 'impossible.' This
is an inappropriate use of the term as it is NOT consistent
with Brooks.)
Post by Philippe Back (High Octane)
I do not agree on using only tables for structures etc. UML (or whatever)
diagrams make a lot of sense for me (I am pretty visual). But with a good
tool, both versions can exist.
More on this point in next reply post.
Post by Philippe Back (High Octane)
The good thing I see there is that there is enough info to get things done
(aligned w/ Parnas's paper on faking a rational process) without getting
overwhelmed.
Yes, Parnas' "Faking It" paper is essential to understanding
Freedom's process charts. The process charts are not literally
prescriptive, but rather document a "rational process" per Parnas.
In so doing, they define the end results to be produced, not
the actual process that must be followed for producing them.
Yet, as Parnas points out in detail, there are many advantages to
explicitly defining a rational process (via charts, etc) even
though it need not be followed literally.

This calls to mind the recent posts regarding phases, and how
the existence of phases presents an intellectual hurdle to be
overcome when learning agile thinking. The same may be said
of process charts. In fact, explicit process charts encompass
this "phases problem" since phases are encompassed by the high
level process charts for many methodologies. Parnas' (and
Freedom's) answer to this is not to throw out process charts
or their phases, but to view them in a new light -- the light
of a "rational process" as described by Parnas. This permits
retaining the benefits of an explicitly defined process while
avoiding its real-world pitfalls. To throw process charts, and
their phases, out is to throw out the baby with the bath water.

Learning agile involves learning a new way of thinking. Part
of that learning experience should be to learn to view process
charts, and their phases, in this new light. The concept of a
Parnas rational process is highly agile in its flexibility and
adaptability to changing development situations. Rather than
teaching prospective agilists that 'phases are out,' it would
be far better to teach them that 'rational processes are in'
and point them to the "Fake It" paper to study:
http://cobolreport.com/columnists/parnas&clements/09152003.asp
There is more benefit in the latter than the former.
Post by Philippe Back (High Octane)
IMV, when someone has reached some level of understanding in methodology, I
guess simplification is in order. Freedom provides that.
You have seen the light!

Thanks again for the good observations, Philippe.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtkf/ Lorillard
===========================================================

This list is now moving to ***@yahoogroups.com.

Please sign up to the new list as we'll soon shut this one down.

Visit www.agilemodeling.com/feedback.htm for details.
--^----------------------------------------------------------------
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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Steven Gordon
2004-03-30 02:32:39 UTC
Permalink
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

I know I personally can work around the phase talk if I need to. For years I have been ignoring phases and doing what works effectively, long before I heard of "agility" or XP.

Nevertheless, propagating the fiction of phases (even just for communication purposes) makes it harder for the uninitiated to see the light. XP is not just doing all the waterfall phases for a small number of requirements in a short period of time. The compression of time provides the freedom to do what makes sense for each task, even if it means sometimes doing the standard phases out of order or piecemeal, or skipping some entirely. The time compression facilitates communication by cooperative learning instead of by writing documents, modeling to work things out together instead of producing a model to communicate your design to whoever has to code it, maintain it, or integrate with it.

The fiction of phases not only makes it hard to gain this holistic view, but it creates an artificial need for people to specialize in a single phase and throw their deliverables over the wall to the next set of specialists. These aritificial walls are difficult barriers to break down after they have been constructed in our minds.

I cannot think of anything that makes it harder for my students to understand agility than the subconscious brainwashing they have been given with respect to phases throughout their education. I think the same may be true of IT managers.

-----Original Message-----
From: Rick Lutowski [mailto:***@jreality.com]
Sent: Monday, March 29, 2004 6:20 PM
To: ***@topica.com
Subject: Re: [AM] Problems ever occur in Agile?


===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWlcrsa/ Ivo Interactive
===========================================================
Post by SChing Chan
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAb7APIWa/ Crazy Aaron Enterprises
===========================================================
Agile software development is a holistic approach that does not have these discrete phases. So, I guess my answer is I do not have any problems with these phases as more.
Phases are an integral part of formal methodologies because
of the problem these methodologies address. Recall that
the earliest methodologies were from the gov't sector,
notably DoD. I was a DoD (Navy) civil servant for 10 years
much of it in the software development area. The following
are based on my recollections:

Management of DoD software projects has always presented
special difficulties because of the nature of the contracting
rules set by Congress. The problem in a nutshell is that
gov't contracting agency employees are prohibited by law
from "managing" the employees of a contractor. A gov't
contracting agency worker cannot tell or suggest (give the
appearance of telling) a contractor employee what to do.
That is the job of contractor management. Severe disciplinary
action can be taken against gov't employees who break this
rule. (They also cannot buy one another gifts, and a lot
of similar restrictions.)

Of course, the gov't contracting agency must have some means
of directing and monitoring the action of the contractor.
As we all know, this need is especially acute in the case
of software development. Given the constraints imposed
by Congress in their infinite wisdom (civil servants use a
number of such euphemisms to make their life more tolerable).
what is the gov't agency to do?

This is the _management_ problem that the infamous waterfall
and other formal methodologies are intended to help solve.

Which brings us to phases.

Phases are time periods during which certain tasks take
place. In DoD and other gov't methodologies, they end
with a formal review in which documents are presented to,
and reviewed by, the contracting agency. Usually there
are also meetings and presentations in which the employees
of both sides are able to get in some face-to-face without
undue fear of being hauled on the carpet for breaking
contracting laws. The contracting agency can approve or
disapprove the work up to that point by approving or
disapproving the documents. The documents thus serve as
a kind of "intermediary" that allow the contracting
agency to direct the work of the contractor without
violating, or appearing to violate, the contracting laws.

So waterfall and other formal, document-driven methodologies
are not inherently bad. Instead, they are "best we can
do" solutions to an inherently bad situation imposed from
above. In actual practice, contracting agencies typically
do whatever they have to do to get the job done, and the
methodologies serve more of a "check the box" function,
which hopefully keeps contracting layers off everbody's
back. Other than that, the are often ignored by the
contractor working level, so their impact on the actual
development is not as severe as might be imagined. This
is why some software developed for the gov't actually
works.

What is bad is when managers in industry or other
organizations not subject to gov't contracting laws
(Federal, state, or local) pick up these methodologies
and use them in place of more efficient management
mechanisms that are NOT prohibited to them as they are
to gov't agencies. You can quess as well as I all the
reasons why private sector managers might do this.

So the first message here is that the holistic agile
approach will not work on gov't projects. If you tried
it, somebody would likely wind up getting fired, or
worse, for breaking the contracting laws.

The second message is to cut formal methodologies a
little slack, at least in the gov't sectors. If it
really bothers you, write your elected officials a
letter and tell them how harmful their contracting
laws are. (But don't expect anything to happen
because they have heard it all before. Congress fancies
itself guided by higher ideals such as "fairness".)

One more thing about phases.

In addition to providing a convenient point of control
for gov't contracting agencies, they can also serve as
convenient descriptive mechanisms for ANY software
development methodology. When used in this way, the
business about ending them with formal reviews of
documents is usually dispensed with. Freedom uses
phases for such descriptive purposes. When methodologies
such as Freedom talk about phases, it should not be
taken to imply that a waterfall must be followed, or
formal reviews must be held, or that the phases cannot
overlap in time, i.e., requirements, design and coding
cannot proceed in parallel. In these methodologies,
phases provide a convenient modularization function
for descriptive purposes. If someone were to fully
automate the methodology at some point, the phases then
might become objects or classes or packages. Nothing
would necessarily precludes them from executing in
parallel (unless maybe it was for a gov't project.)

So the third message is that, for methodologies like
Freedom that use phases for descriptive rather than
management control purposes, phases and agile's
holistic approach are _not_ mutually exclusive.
--
Rick Lutowski
Principal, JReality
***@jreality.com
http://www.jreality.com

===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWlcrsf/ Lorillard
===========================================================

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

===========================================================
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab3ozbUrKDAbWnbtkf/ Ivo Interactive
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
p***@aol.com
2004-03-30 04:03:49 UTC
Permalink
===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtka/ Crazy Aaron Enterprises
===========================================================

In a message dated 3/29/2004 6:38:51 PM Pacific Standard Time,
***@asu.edu writes:
I cannot think of anything that makes it harder for my students to understand
agility than the subconscious brainwashing they have been given with respect
to phases throughout their education. I think the same may be true of IT
managers.
Steven:

Right on!.

When I began my career as a softare developer in the U.S. Air Force, I had
visions of getting in "on the gound floor" of a "dynamic and exciting new
field". I should have read the fine print. Experience has taught me that the
majority of software developers and their managers comprise one of the most
conservative and "tight-butted" groups I've ever seen or had to work with. I have on
many occasions described those of my clients who elected to give agile a try as
"Desperate or Daring", and that about sums it up. Of course, so far, they
could also be described as "Successful", at least as far as the projects in which
I was involved as a developer are concerned. I attribute their aversion to
just about anything other than the phased waterfall approach to their training,
their aversion to try anything new, and pressure from the bean counters to
comply with the standard project costing models.

Regards,

Pete

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Gaythorpe, Dagna
2004-03-30 08:38:40 UTC
Permalink
===========================================================
Menthol Smokers Only! Click on the link below and
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAbWnbtka/ Lorillard
===========================================================

Back in the early '90s ('91 to '96') I used to work for Ernst & Young, who
had their own methodology (Navigator). The documentation filled a 'wardrobe'
type cupboard, and the basic course we all got sent on lasted a week.

The very first thing they told us was that no part of the methodology was
required. The second thing was that we should pick out the bits that the
project needed, right down to the lowest level of granularity so, from one
big phase, we might just use one short document or interview type - or
nothing at all. I have been using this approach ever since (although I am
not, and never have been, any sort of project manager. I have successfully
avoided accusations of 'management' so far. <g>)

It has just occurred to me to wonder - was this an early attempt at agility?
Or was it just recognition that the clients didn't necessarily appreciate
getting a couple of forests worth of stuff to read and sign off?

Regards,

Dagna

Dagna Gaythorpe
Data Architect
International IT
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



-----Original Message-----
From: Steven Gordon [mailto:***@asu.edu
<mailto:***@asu.edu> ]

I know I personally can work around the phase talk if I need to. For years
I have been ignoring phases and doing what works effectively, long before I
heard of "agility" or XP.

Nevertheless, propagating the fiction of phases (even just for communication
purposes) makes it harder for the uninitiated to see the light. XP is not
just doing all the waterfall phases for a small number of requirements in a
short period of time. The compression of time provides the freedom to do
what makes sense for each task, even if it means sometimes doing the
standard phases out of order or piecemeal, or skipping some entirely. The
time compression facilitates communication by cooperative learning instead
of by writing documents, modeling to work things out together instead of
producing a model to communicate your design to whoever has to code it,
maintain it, or integrate with it.

The fiction of phases not only makes it hard to gain this holistic view, but
it creates an artificial need for people to specialize in a single phase and
throw their deliverables over the wall to the next set of specialists.
These aritificial walls are difficult barriers to break down after they have
been constructed in our minds.

I cannot think of anything that makes it harder for my students to
understand agility than the subconscious brainwashing they have been given
with respect to phases throughout their education. I think the same may be
true of IT managers.



*************************************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Beaufort House, 15 St. Botolph Street, London, EC3A 7QN
Tel. +44 20 7390 3900


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.
*************************************************************************************

===========================================================
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up
handfuls. It's the creativity unleashing, mood enhancing
desk toy!
http://click.topica.com/caab4CEbUrKDAbWnbtkf/ Crazy Aaron Enterprises
===========================================================

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

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
Loading...