Paul Oldfield
2004-02-26 16:26:08 UTC
(responding to Pete)
Since my intoduction to this forum several months ago, one of
the things that struck me regarding the comments of new
participants regarding "agility" in general and agile modeling in
particular was an expectation that there was a well-defined
step-by-step "formula" that, properly applied, would lead to
universal success in developing software.
In a way, there is... but then in another way, there isn't...
To produce a product, one performs a sequence of actions.
There may be many possible sequences of actions that
would produce the same product, or one that was equally
good for the purpose. In this respect, there is a step-by-
step formula for producing the product. However, unless the
product you want to produce is exactly identical to the last
one, the steps will differ to some degree. At minimum, the
requirements supplied will differ.
One thing that distinguishes agile approaches from
traditional is how one arrives at the sequence of steps by
which the product is produced. Traditional approaches
will typically have a set of predefined steps that leave just
enough 'wiggle room' to produce a different product. To the
traditional mindset, the ideal process would allow the
initial requirements to change between projects, but all
else would be fixed. Any subsequent difference is
derived directly from the difference in the requirements and
how this impacts on the rules of the process.
Agile processes need to deal with more change of different
sorts, and cannot hope to have predefined rules for all
eventualities. In many more cases, the choice of what is the
next step in the process is left to the person who has to
make that step. This person needs to have the knowledge
of the options, and the wisdom to choose the most
appropriate option. Ideally, he has the experience of the
entire team to help in making this decision; sometimes he
will need it.
question than "What is agile?"
Of course, 'appropriate' cannot be detached from a situation,
while 'agile' can. That distinction is significant. No process
is intrinsically appropriate, even the most agile of processes.
there? Pete? ... Anybody??? ;-)
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
--^----------------------------------------------------------------
(Paul)
Of course, my personal belief is that we should *always* use
appropriate methods.
(Pete)Of course, my personal belief is that we should *always* use
appropriate methods.
Since my intoduction to this forum several months ago, one of
the things that struck me regarding the comments of new
participants regarding "agility" in general and agile modeling in
particular was an expectation that there was a well-defined
step-by-step "formula" that, properly applied, would lead to
universal success in developing software.
To produce a product, one performs a sequence of actions.
There may be many possible sequences of actions that
would produce the same product, or one that was equally
good for the purpose. In this respect, there is a step-by-
step formula for producing the product. However, unless the
product you want to produce is exactly identical to the last
one, the steps will differ to some degree. At minimum, the
requirements supplied will differ.
One thing that distinguishes agile approaches from
traditional is how one arrives at the sequence of steps by
which the product is produced. Traditional approaches
will typically have a set of predefined steps that leave just
enough 'wiggle room' to produce a different product. To the
traditional mindset, the ideal process would allow the
initial requirements to change between projects, but all
else would be fixed. Any subsequent difference is
derived directly from the difference in the requirements and
how this impacts on the rules of the process.
Agile processes need to deal with more change of different
sorts, and cannot hope to have predefined rules for all
eventualities. In many more cases, the choice of what is the
next step in the process is left to the person who has to
make that step. This person needs to have the knowledge
of the options, and the wisdom to choose the most
appropriate option. Ideally, he has the experience of the
entire team to help in making this decision; sometimes he
will need it.
This expectation has been the cause of much debate, and in
several cases, somewhat heated exchanges, regarding just
what constitutes agilility. Your comment regarding "appropriate
methods", above, seems to strike at the heart of this issue.
I certainly regard "What is appropriate?" as a more importantseveral cases, somewhat heated exchanges, regarding just
what constitutes agilility. Your comment regarding "appropriate
methods", above, seems to strike at the heart of this issue.
question than "What is agile?"
Of course, 'appropriate' cannot be detached from a situation,
while 'agile' can. That distinction is significant. No process
is intrinsically appropriate, even the most agile of processes.
For some time now, I have suspected that the form of agility
implied in the principles of the Agile Manifesto, and described
and embraced by the contributors heer, requires either a fairly
extensive body of development experience or a substantial
"leap of faith" in order to understand that agility and appropriate
methods are essentially two side of the same coin. This is not
necessarily intuitively obvious to the uninitiated, particularly
those earnestly searching for a better way to build software, and
it may account for many of the misunderstandings that have
arisen on this subject.
I may not be the brightest bulb in the box,
Get your light out from under that bushel that's hiding it ;-)implied in the principles of the Agile Manifesto, and described
and embraced by the contributors heer, requires either a fairly
extensive body of development experience or a substantial
"leap of faith" in order to understand that agility and appropriate
methods are essentially two side of the same coin. This is not
necessarily intuitively obvious to the uninitiated, particularly
those earnestly searching for a better way to build software, and
it may account for many of the misunderstandings that have
arisen on this subject.
I may not be the brightest bulb in the box,
so I could be way off base here, but it seems to me that there
seems to be some minimum level of knowledge or experience
required to understand and appreciate the general concept of
agility.
I don't know whether it's *necessary*, but it definitely helps, IMHO.seems to be some minimum level of knowledge or experience
required to understand and appreciate the general concept of
agility.
I am sure that many of us have been called upon to describe
agility, and it sometimes feels to me like I'm trying to describe
the Golden Rule to the infidels; that is, I uually have to provide
a brief summary of the history of sofware development to put
the concept of agility in an appropriate context before the light
bulb overhead gets turned on. Is my experience unique, or am
I just an inadequate spokeperson for agility? How do the rest
of you hep others to understand agility and its benefits?
I just keep talking until they get it or go away... Pete? You stillagility, and it sometimes feels to me like I'm trying to describe
the Golden Rule to the infidels; that is, I uually have to provide
a brief summary of the history of sofware development to put
the concept of agility in an appropriate context before the light
bulb overhead gets turned on. Is my experience unique, or am
I just an inadequate spokeperson for agility? How do the rest
of you hep others to understand agility and its benefits?
there? Pete? ... Anybody??? ;-)
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
--^----------------------------------------------------------------