Discussion:
[AM] The Spiral Model
guillermo camilo
2004-02-12 21:13:49 UTC
Permalink
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer

What is the main differences between the spiral model's concepts and the
core of the agile methodologies???

i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?

pls help
i would welcome any comment you could have about this matter...
thanks in advance

Guillermo Camilo
***@unsa.edu.pe

www.lanoosfera.com
www.oolanoosfera.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
--^----------------------------------------------------------------
J. B. Rainsberger
2004-02-12 21:29:49 UTC
Permalink
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer
What is the main differences between the spiral model's concepts and the
core of the agile methodologies???
i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?
One thing in common: Spiral and Agile include generating feedback as a
key practice. One difference: Agile makes specific comments about
communication, simplicity and courage, whereas Spiral does not.

A group of six people, each working on the same project, each working on
separate components, each working iteratively... this can be Spiral, but
it cannot be Agile. To be Agile, they would need to work as a team.

There's more, but that's one key difference.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
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
--^----------------------------------------------------------------
Steven Gordon
2004-02-12 23:11:20 UTC
Permalink
In a typical XP or Scrum project, the customer can expect working software with some business functionality every few weeks, including within the very first month. In a Spiral project, the amount of time spent on requirements, analysis, design and architecture prior to producing the first software deliverable with any business functionality could be much longer than one month.

If you take Spiral to the extreme that you build some new business functionality every few weeks, then you would be approaching agility. This would end up forcing us to focus on only a few features. The requirements, analysis, design, implementation, and testing phases would become so short and focussed that they become seamlessly integrated work done by the whole team rather than being distinct phases done by different people. The shortened time frame would also makes it possible to directly communicate and collaborate on the current focus now until it is done (instead of communicating via documents so we do not forgot what was supposed to be implemented or tested when somebody else gets to it some time later).

Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer
What is the main differences between the spiral model's concepts and the
core of the agile methodologies???
i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?
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
--^----------------------------------------------------------------
M***@Graybill.com
2004-02-13 00:11:36 UTC
Permalink
Steve,

Oh how often we get stuck on terms - it is often just,
simply one term versus another, and what meaning is
attributed to each that is different for each of us.
There is obviously something about the term Spiral you
don't like. Otherwise, your last paragraph discerns no
difference between one use of Spiral, and XP, although
you say it only approaches agility.

Is your statement an attempt to "protect" XP or
agility, or is there something more to your last
paragraph?

The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isn’t it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me I’m wrong.

Prove me wrong - that is - prove. ;)

Mark
Post by Steven Gordon
In a typical XP or Scrum project, the customer can
expect working software with some business
functionality every few weeks, including within the
very first month. In a Spiral project, the amount of
time spent on requirements, analysis, design and
architecture prior to producing the first software
deliverable with any business functionality could be
much longer than one month.
If you take Spiral to the extreme that you build some
new business functionality every few weeks, then you
would be approaching agility. This would end up
forcing us to focus on only a few features. The
requirements, analysis, design, implementation, and
testing phases would become so short and focussed that
they become seamlessly integrated work done by the
whole team rather than being distinct phases done by
different people. The shortened time frame would also
makes it possible to directly communicate and
collaborate on the current focus now until it is done
(instead of communicating via documents so we do not
forgot what was supposed to be implemented or tested
when somebody else gets to it some time later).
Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the
spiral model for software
Post by guillermo camilo
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of
you, wouldn't bother to
Post by guillermo camilo
help me to find the answer
What is the main differences between the spiral
model's concepts and the
Post by guillermo camilo
core of the agile methodologies???
i see both of them are , in essence, iterative and
incremental, so. how are
Post by guillermo camilo
we going to differentiate them?
For more information about AM, visit the Agile
Modeling
Post by Steven Gordon
Home Page at www.agilemodeling.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein

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
2004-02-13 00:24:50 UTC
Permalink
XP requires compression down to time periods on the order of a week or two, whereas I believe Spiral does not. This makes a big difference.

If you do timebox Spiral down to software deliveries on the order of a few weeks, you still have several supporting practices to add before you would have XP. But, whether you would have agility depends more on attitude and flexibility than these additional practices.

Before the emergence of RUP, I believe most real world implementations of Spiral really did prototyping in the first phase and then normal waterfall in the second phase, in order to reduce the risk of going straight to normal waterfall. Now, I would say the vast majority of Spiral projects are RUP.

-----Original Message-----
From: ***@Graybill.com [mailto:***@Graybill.com]
Sent: Thursday, February 12, 2004 5:12 PM
To: ***@topica.com
Subject: RE: [AM] The Spiral Model


Steve,

Oh how often we get stuck on terms - it is often just,
simply one term versus another, and what meaning is
attributed to each that is different for each of us.
There is obviously something about the term Spiral you
don't like. Otherwise, your last paragraph discerns no
difference between one use of Spiral, and XP, although
you say it only approaches agility.

Is your statement an attempt to "protect" XP or
agility, or is there something more to your last
paragraph?

The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isn't it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me I'm wrong.

Prove me wrong - that is - prove. ;)

Mark
Post by Steven Gordon
In a typical XP or Scrum project, the customer can
expect working software with some business
functionality every few weeks, including within the
very first month. In a Spiral project, the amount of
time spent on requirements, analysis, design and
architecture prior to producing the first software
deliverable with any business functionality could be
much longer than one month.
If you take Spiral to the extreme that you build some
new business functionality every few weeks, then you
would be approaching agility. This would end up
forcing us to focus on only a few features. The
requirements, analysis, design, implementation, and
testing phases would become so short and focussed that
they become seamlessly integrated work done by the
whole team rather than being distinct phases done by
different people. The shortened time frame would also
makes it possible to directly communicate and
collaborate on the current focus now until it is done
(instead of communicating via documents so we do not
forgot what was supposed to be implemented or tested
when somebody else gets to it some time later).
Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the
spiral model for software
Post by guillermo camilo
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of
you, wouldn't bother to
Post by guillermo camilo
help me to find the answer
What is the main differences between the spiral
model's concepts and the
Post by guillermo camilo
core of the agile methodologies???
i see both of them are , in essence, iterative and
incremental, so. how are
Post by guillermo camilo
we going to differentiate them?
For more information about AM, visit the Agile
Modeling
Post by Steven Gordon
Home Page at www.agilemodeling.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein

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
--^----------------------------------------------------------------
Mark Graybill
2004-02-13 04:23:31 UTC
Permalink
I see - you are talking about implementations of it that you've seen.

I should have clarified. I'm refering to the main concept of Spiral, which
is for the purpose of evolutionary development. What is being taught about
Spiral today does not refer to specific implementations, but rather as
methodological concept. (i.e. Sommerville 2001; SWEBOK)

However, I was abstracting it perhaps a bit more and applying it to Agile,
seeing that each main section of a single spiral iteration is accomplished
in some for with Agile methods.

Mark

----- Original Message -----
From: "Steven Gordon" <***@asu.edu>
To: <***@topica.com>
Sent: Thursday, February 12, 2004 6:24 PM
Subject: RE: [AM] The Spiral Model
Post by Steven Gordon
XP requires compression down to time periods on the order of a week or
two, whereas I believe Spiral does not. This makes a big difference.
Post by Steven Gordon
If you do timebox Spiral down to software deliveries on the order of a few
weeks, you still have several supporting practices to add before you would
have XP. But, whether you would have agility depends more on attitude and
flexibility than these additional practices.
Post by Steven Gordon
Before the emergence of RUP, I believe most real world implementations of
Spiral really did prototyping in the first phase and then normal waterfall
in the second phase, in order to reduce the risk of going straight to normal
waterfall. Now, I would say the vast majority of Spiral projects are RUP.
Post by Steven Gordon
-----Original Message-----
Sent: Thursday, February 12, 2004 5:12 PM
Subject: RE: [AM] The Spiral Model
Steve,
Oh how often we get stuck on terms - it is often just,
simply one term versus another, and what meaning is
attributed to each that is different for each of us.
There is obviously something about the term Spiral you
don't like. Otherwise, your last paragraph discerns no
difference between one use of Spiral, and XP, although
you say it only approaches agility.
Is your statement an attempt to "protect" XP or
agility, or is there something more to your last
paragraph?
The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isn't it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me I'm wrong.
Prove me wrong - that is - prove. ;)
Mark
Post by Steven Gordon
In a typical XP or Scrum project, the customer can
expect working software with some business
functionality every few weeks, including within the
very first month. In a Spiral project, the amount of
time spent on requirements, analysis, design and
architecture prior to producing the first software
deliverable with any business functionality could be
much longer than one month.
If you take Spiral to the extreme that you build some
new business functionality every few weeks, then you
would be approaching agility. This would end up
forcing us to focus on only a few features. The
requirements, analysis, design, implementation, and
testing phases would become so short and focussed that
they become seamlessly integrated work done by the
whole team rather than being distinct phases done by
different people. The shortened time frame would also
makes it possible to directly communicate and
collaborate on the current focus now until it is done
(instead of communicating via documents so we do not
forgot what was supposed to be implemented or tested
when somebody else gets to it some time later).
Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the
spiral model for software
Post by guillermo camilo
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of
you, wouldn't bother to
Post by guillermo camilo
help me to find the answer
What is the main differences between the spiral
model's concepts and the
Post by guillermo camilo
core of the agile methodologies???
i see both of them are , in essence, iterative and
incremental, so. how are
Post by guillermo camilo
we going to differentiate them?
For more information about AM, visit the Agile
Modeling
Post by Steven Gordon
Home Page at www.agilemodeling.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein
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
--^----------------------------------------------------------------
Brad Appleton
2004-02-13 04:45:58 UTC
Permalink
Post by guillermo camilo
What is the main differences between the spiral model's concepts
and the core of the agile methodologies???
i see both of them are, in essence, iterative and incremental,
so. how are we going to differentiate them?
How might one differentiate between PairProgramming and XP,
or TDD and XP? To me your question is similar.

I think the spiral model is first and foremost a model for
a software lifecycle. And XP is a methodology (or method if
you prefer) that utilizes a spiral model, as well as utilizing
many other things. I think a development lifecycle model and
a development methodology are different things, and that the
latter employs the former plus a whole lot more.

At its core, the spiral model says develop in an iterative and
incremental fashion driven by risk analysis/mitigation. XP
and agile methodologies felsh this out a whole lot more,
and add practices specific practices for how/when to do it,
and principles/values to guide in the how/why of applying
those practices.
--
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

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
2004-02-13 05:02:41 UTC
Permalink
Do you know of any agile real-world instantiations of Spiral?

-----Original Message-----
From: Mark Graybill [mailto:***@Graybill.com]
Sent: Thu 2/12/2004 9:23 PM
To: ***@topica.com
Cc:
Subject: Re: [AM] The Spiral Model

I see - you are talking about implementations of it that you've seen.

I should have clarified. I'm refering to the main concept of Spiral, which
is for the purpose of evolutionary development. What is being taught about
Spiral today does not refer to specific implementations, but rather as
methodological concept. (i.e. Sommerville 2001; SWEBOK)

However, I was abstracting it perhaps a bit more and applying it to Agile,
seeing that each main section of a single spiral iteration is accomplished
in some for with Agile methods.

Mark

----- Original Message -----
From: "Steven Gordon" <***@asu.edu>
To: <***@topica.com>
Sent: Thursday, February 12, 2004 6:24 PM
Subject: RE: [AM] The Spiral Model
Post by Steven Gordon
XP requires compression down to time periods on the order of a week or
two, whereas I believe Spiral does not. This makes a big difference.
Post by Steven Gordon
If you do timebox Spiral down to software deliveries on the order of a few
weeks, you still have several supporting practices to add before you would
have XP. But, whether you would have agility depends more on attitude and
flexibility than these additional practices.
Post by Steven Gordon
Before the emergence of RUP, I believe most real world implementations of
Spiral really did prototyping in the first phase and then normal waterfall
in the second phase, in order to reduce the risk of going straight to normal
waterfall. Now, I would say the vast majority of Spiral projects are RUP.
Post by Steven Gordon
-----Original Message-----
Sent: Thursday, February 12, 2004 5:12 PM
Subject: RE: [AM] The Spiral Model
Steve,
Oh how often we get stuck on terms - it is often just,
simply one term versus another, and what meaning is
attributed to each that is different for each of us.
There is obviously something about the term Spiral you
don't like. Otherwise, your last paragraph discerns no
difference between one use of Spiral, and XP, although
you say it only approaches agility.
Is your statement an attempt to "protect" XP or
agility, or is there something more to your last
paragraph?
The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isn't it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me I'm wrong.
Prove me wrong - that is - prove. ;)
Mark
Post by Steven Gordon
In a typical XP or Scrum project, the customer can
expect working software with some business
functionality every few weeks, including within the
very first month. In a Spiral project, the amount of
time spent on requirements, analysis, design and
architecture prior to producing the first software
deliverable with any business functionality could be
much longer than one month.
If you take Spiral to the extreme that you build some
new business functionality every few weeks, then you
would be approaching agility. This would end up
forcing us to focus on only a few features. The
requirements, analysis, design, implementation, and
testing phases would become so short and focussed that
they become seamlessly integrated work done by the
whole team rather than being distinct phases done by
different people. The shortened time frame would also
makes it possible to directly communicate and
collaborate on the current focus now until it is done
(instead of communicating via documents so we do not
forgot what was supposed to be implemented or tested
when somebody else gets to it some time later).
Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
Post by guillermo camilo
hi everybody
after a list of readings about this subject , the
spiral model for software
Post by guillermo camilo
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of
you, wouldn't bother to
Post by guillermo camilo
help me to find the answer
What is the main differences between the spiral
model's concepts and the
Post by guillermo camilo
core of the agile methodologies???
i see both of them are , in essence, iterative and
incremental, so. how are
Post by guillermo camilo
we going to differentiate them?
For more information about AM, visit the Agile
Modeling
Post by Steven Gordon
Home Page at www.agilemodeling.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com
Post by Steven Gordon
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
2004-02-13 08:51:20 UTC
Permalink
(responding to Mark, All)
Post by M***@Graybill.com
The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isnt it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me Im wrong.
AFAICS, the Sprial Model is *one* best practice that is
almost universally applicable in agile methodologies.

If we take XP as an example, a constrained variant of the
Spiral Model is one of 12 best practices that XP considers
to be universally applicable wherever XP is appropriate.

However, we must also consider that 'agility' is a lot more
than any set of best practices, it includes the value system
and principles that allow us to select the best practices
that are appropriate to our situation, and to re-visit that
decision as often as is necessary.

If you want a short definition, agility is whatever it takes to
be able to respond effectively to changing circumstances.
(That's just a quick off-the-cuff definition, I wouldn't want to
have to support it in court ;-) ). As such, the Spiral Model is
a *single* step in that direction, but on its own it is far from
adequate, and it is at the mercy of the people enacting it
as a process.


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
--^----------------------------------------------------------------
Mark Graybill
2004-02-15 01:36:04 UTC
Permalink
Excellent point Paul!

----- Original Message -----
From: "Paul Oldfield" <***@compuserve.com>
To: <***@topica.com>
Sent: Friday, February 13, 2004 2:51 AM
Subject: RE: [AM] The Spiral Model
Post by Paul Oldfield
(responding to Mark, All)
Post by M***@Graybill.com
The fundamental precepts behind the Spiral method are
identical to Agile and even XP. Isnt it possible that
Agile concepts found something that is fundamental,
underlying a successful project that was found before -
and now we are splitting hair over terms? Please tell
me Im wrong.
AFAICS, the Sprial Model is *one* best practice that is
almost universally applicable in agile methodologies.
If we take XP as an example, a constrained variant of the
Spiral Model is one of 12 best practices that XP considers
to be universally applicable wherever XP is appropriate.
However, we must also consider that 'agility' is a lot more
than any set of best practices, it includes the value system
and principles that allow us to select the best practices
that are appropriate to our situation, and to re-visit that
decision as often as is necessary.
If you want a short definition, agility is whatever it takes to
be able to respond effectively to changing circumstances.
(That's just a quick off-the-cuff definition, I wouldn't want to
have to support it in court ;-) ). As such, the Spiral Model is
a *single* step in that direction, but on its own it is far from
adequate, and it is at the mercy of the people enacting it
as a process.
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
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
--^----------------------------------------------------------------
Barr Bill P
2004-02-13 13:42:09 UTC
Permalink
Post by Steven Gordon
If you take Spiral to the extreme that you build some new business
functionality every few weeks, then you would be approaching agility. This
would end up forcing us to focus on only a few features. The requirements,

Doesn't this pretty much describe the RUP's implementation of the Spiral
model?

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
--^----------------------------------------------------------------
Scott E. Preece
2004-02-13 14:38:01 UTC
Permalink
Tom Gilb described Evloutionary development in 1985. That's the root of
the iterative/incremental approach to building software - prioritize,
build a little, evaluate with the customer. This approach works toward
five of the twelve XP practices (Planning Process, Small Releases,
Refactoring, Customer On-Site, and Continuous Integration).

Barry Boehm presented the Spiral model in 1986 in ACM SIGSOFT Software
Engineering Notes and two years later in IEEE Computer. It's
significantly different from XP: the iterations produce
"increasingly detailed elaborations of the system", where agile methods
try to produce increasingly complete systems. The Spiral Model applies
the same sequence of activities in each cycle: elaborate the objectives,
evaluate alternatives, elaborate the product definition, plan the next
round. You don't typically start coding until the fourth or fifth
iteration - in the first iteration the "product definition" is
elaborated as requirements, in the second as analysis, in the third as
design, etc. There is an explicit risk evaluation in each iteration,
with the possibility of stopping the project. Once coding starts, the
iterations continue and do implement the system in an incremental,
iterative fashion.

Both Gilb and Boehm emphasize the importance of customer (and other
stakeholder) involvement throughout.

I think a lot of agilists would say that what they do actually maps well
to the Spiral model - that the first few elaborative cycles (the ones
preceding the start of coding) simply happen very rapidly and
informally, often in single meetings of all the stakeholders.

scott

| From: Barr Bill P<***@irs.gov>
| Date: Fri, 13 Feb 2004 08:42:09 -0500
|
| This is a multipart message; text/plain parts are shown here;
| use ":" to see non-text parts.
| ----------------------------------------
| Part 1:
| Content-Type: text/plain
|
| >If you take Spiral to the extreme that you build some new business
| functionality every few weeks, then you would be approaching agility. This
| would end up forcing us to focus on only a few features. The requirements,
|
| Doesn't this pretty much describe the RUP's implementation of the Spiral
| model?
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|
| ------_=_NextPart_001_01C3F236.FDC6B11E
| ----------------------------------------
| Part 2: text/html
| ----------------------------------------
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: 217-384-8550
phone: 217-384-8589 cell: 217-433-6114 pager: ***@msg.myvzw.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
2004-02-13 14:40:14 UTC
Permalink
Exactly.

And there have been several discussions here why RUP in theory approaches agility, but very few real world instantiations of it are actually as agile as most instantiations of XP, Scrum, and other agile methodologies.

If I recall, I came away from those discussions concluding that what makes RUP not agile in practice are:
- the huge menu of practices to choose from makes it difficult to start from a small enough set of practices to stay lightweight.
- the accompanying document-centric tool set also makes it hard to stay lightweight.
- the first phase is devoted to determining an architecture given the initial requirements, thus not delivering any business functionality early enough the customer to prime the requirement refinement pump. This increases the cost of change, thus discouraging the requirement refinement pump from ever becoming more than a trickle compared to true agility.

-----Original Message-----
From: Barr Bill P [mailto:***@irs.gov]
Sent: Fri 2/13/2004 6:42 AM
To: '***@topica.com'
Cc:
Subject: RE: [AM] The Spiral Model
Post by Steven Gordon
If you take Spiral to the extreme that you build some new business
functionality every few weeks, then you would be approaching agility. This
would end up forcing us to focus on only a few features. The requirements,

Doesn't this pretty much describe the RUP's implementation of the Spiral
model?

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
--^----------------------------------------------------------------
Barr Bill P
2004-02-13 15:16:11 UTC
Permalink
Post by Steven Gordon
If I recall, I came away from those discussions concluding
- the huge menu of practices to choose from makes it
difficult to start from a small enough set of practices to
stay lightweight.
Oh, how true. To placate the CMM crowd, I say we are using RUP. In practice,
I am enthusiastically culling the artifact list, just as RUP advises.
Post by Steven Gordon
- the accompanying document-centric tool set also makes it
hard to stay lightweight.
I use the tools to generate docs from the code to keep those who measure the
value of documentation not by function, but by weight, happy.
Post by Steven Gordon
- the first phase is devoted to determining an architecture
given the initial requirements, thus not delivering any
business functionality early enough the customer to prime the
requirement refinement pump. This increases the cost of
We never get requirements from customers. We only get arcane requests and
statements of needs. As far as I can tell, a "need" is just their vision of
a requirement. We still have to translate those "needs" into geek-speak. No
way around that. In that respect, use cases, use case diagrams, CRC cards
and activity diagrams are incredibly helpful in extracting requirements.

One RUP practice that does help a lot is to break the system up into
components as quickly as possible. Once that is done, choose one component
and focus on that. This does allow for agility and helps to get something
out the door, faster.

Of course, having some agile DBAs on staff who say, "Don't worry, we can add
that later," or, "The design is flexible enough to extend the schema," is
extremely helpful!

Once we've been through a couple iterations and have pruned RUP
sufficiently, I'll do my best to write a message about the experience.

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
2004-02-13 15:28:59 UTC
Permalink
Excellent - the industry needs case studies of successfully using RUP in an agile manner.

-----Original Message-----
From: Barr Bill P [mailto:***@irs.gov]
Sent: Fri 2/13/2004 8:16 AM
To: '***@topica.com'
Cc:
Subject: RE: [AM] The Spiral Model
Post by Steven Gordon
If I recall, I came away from those discussions concluding
- the huge menu of practices to choose from makes it
difficult to start from a small enough set of practices to
stay lightweight.
Oh, how true. To placate the CMM crowd, I say we are using RUP. In practice,
I am enthusiastically culling the artifact list, just as RUP advises.
Post by Steven Gordon
- the accompanying document-centric tool set also makes it
hard to stay lightweight.
I use the tools to generate docs from the code to keep those who measure the
value of documentation not by function, but by weight, happy.
Post by Steven Gordon
- the first phase is devoted to determining an architecture
given the initial requirements, thus not delivering any
business functionality early enough the customer to prime the
requirement refinement pump. This increases the cost of
We never get requirements from customers. We only get arcane requests and
statements of needs. As far as I can tell, a "need" is just their vision of
a requirement. We still have to translate those "needs" into geek-speak. No
way around that. In that respect, use cases, use case diagrams, CRC cards
and activity diagrams are incredibly helpful in extracting requirements.

One RUP practice that does help a lot is to break the system up into
components as quickly as possible. Once that is done, choose one component
and focus on that. This does allow for agility and helps to get something
out the door, faster.

Of course, having some agile DBAs on staff who say, "Don't worry, we can add
that later," or, "The design is flexible enough to extend the schema," is
extremely helpful!

Once we've been through a couple iterations and have pruned RUP
sufficiently, I'll do my best to write a message about the experience.

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
--^----------------------------------------------------------------
Charlie Poole
2004-02-14 06:05:59 UTC
Permalink
Having read the question and ensuing answers I'm struck that nobody has
mentioned this:

Agile methods deal with people and how they work together. Historically,
this has been
"out of scope" for software development methodologies. If we compare
approaches while
abstracting away this important difference, they may appear similar, just as
an auto
is like a wagon if you abstract away the source of motive power.

When we choose to abstract away people in our discussion, we are being
non-agile ourselves.

Charlie Poole
***@pooleconsulting.com
www.pooleconsulting.com
www.charliepoole.org
Post by Steven Gordon
-----Original Message-----
Sent: Thursday, February 12, 2004 1:14 PM
Subject: [AM] The Spiral Model
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer
What is the main differences between the spiral model's concepts and the
core of the agile methodologies???
i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?
pls help
i would welcome any comment you could have about this matter...
thanks in advance
Guillermo Camilo
www.lanoosfera.com
www.oolanoosfera.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
--^----------------------------------------------------------------
Scott Ambler
2004-02-14 14:27:26 UTC
Permalink
I agree with Charlie.

On a tangential note, here's an observation that I made about Spiral a few
years ago in my Process Patterns book:

The main advantage of the Spiral Development process pattern is that it is
a more realistic look at software development, as it recognizes the fact
that you often must revisit each project phase throughout the development
process. It also directly includes prototyping as a project phase,
providing the opportunity to include users to a greater extent in the
development process. The disadvantages of the Spiral SDLC include the fact
that it is complex and that it still is not completely accurate: sometimes
we realize during one phase that we need to immediately go back and redo a
previous one, perhaps go from prototyping directly back to risk analysis,
without continuing on to the next phase.

The paragraph above accompanied a diagram of the spiral lifecycle. In the
diagram you "spiral through" requirements, requirements validation,
analysis, .... basically mini-waterfalls. That's what I was saying wasn't
accurate, IMHO.

- Scott
Post by Charlie Poole
Having read the question and ensuing answers I'm struck that nobody has
Agile methods deal with people and how they work together. Historically,
this has been
"out of scope" for software development methodologies. If we compare
approaches while
abstracting away this important difference, they may appear similar, just as
an auto
is like a wagon if you abstract away the source of motive power.
When we choose to abstract away people in our discussion, we are being
non-agile ourselves.
Charlie Poole
www.pooleconsulting.com
www.charliepoole.org
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
--^----------------------------------------------------------------
Mark Graybill
2004-02-15 02:03:18 UTC
Permalink
----- Original Message -----
From: "Scott Ambler" <***@ronin-intl.com>
To: <***@topica.com>
Sent: Saturday, February 14, 2004 8:27 AM
Subject: RE: [AM] The Spiral Model
Post by Scott Ambler
I agree with Charlie.
Re: previous post. Also, I don't see a particular connection between the
Agile Manifesto and Spiral.
Post by Scott Ambler
On a tangential note, here's an observation that I made about Spiral a few
The main advantage of the Spiral Development process pattern is that it is
a more realistic look at software development, as it recognizes the fact
that you often must revisit each project phase throughout the development
process. It also directly includes prototyping as a project phase,
providing the opportunity to include users to a greater extent in the
development process. The disadvantages of the Spiral SDLC include the fact
that it is complex and that it still is not completely accurate: sometimes
we realize during one phase that we need to immediately go back and redo a
previous one, perhaps go from prototyping directly back to risk analysis,
without continuing on to the next phase.
Good point. The Spiral methodology, as it has been described recently and
is being taught, has no explicit activity dedicated to handle such a case as
you describe. However, it could be argued that the description of the last
defined activity in a spiral implicitly, the planning activity, includes the
possibility to replan the current spiral if the decision is not made to
continue to the next spiral.

If one were to devise criterion based "exit" and "re-entry" points available
for each spiral, if you must have rigidity, or otherwise, a single override
activity to exit re-enter anywhere as appropriate, then perhaps it wouldn't
be such a disadvantage.
Post by Scott Ambler
The paragraph above accompanied a diagram of the spiral lifecycle. In the
diagram you "spiral through" requirements, requirements validation,
analysis, .... basically mini-waterfalls. That's what I was saying wasn't
accurate, IMHO.
I remember a rather silly discussion here about mini-waterfalls. To avoid a
similar discussion resulting from a comment here, is that there are certain
activities unavoidable in good software development.

1. Conceptualize what will be done such as the design or the test in TDD, or
scribbles on paper before something is coded - or at least the thought
paths - or thought then code cycles that occur during the conceptualization
of what is coded.
2. Something is coded.
3. The code is verified, either by planning or by operational use (e.g.
customer says it doesn't do what he said it should do.)

One therefore could argue that this is design, code, test, or a
mini-waterfall.

Not sure what you mean by your last sentence.
Post by Scott Ambler
- Scott
Post by Charlie Poole
Having read the question and ensuing answers I'm struck that nobody has
Agile methods deal with people and how they work together. Historically,
this has been
"out of scope" for software development methodologies. If we compare
approaches while
abstracting away this important difference, they may appear similar, just as
an auto
is like a wagon if you abstract away the source of motive power.
When we choose to abstract away people in our discussion, we are being
non-agile ourselves.
Charlie Poole
www.pooleconsulting.com
www.charliepoole.org
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
--^----------------------------------------------------------------
J. B. Rainsberger
2004-02-14 18:37:43 UTC
Permalink
Post by Charlie Poole
Having read the question and ensuing answers I'm struck that nobody has
Agile methods deal with people and how they work together.
This is such an intrinsic part of my approach that I do not think to
mention it explicitly. For me, it's like mentioning that it's important
to breathe.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
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
--^----------------------------------------------------------------
Mark Graybill
2004-02-15 01:50:28 UTC
Permalink
The Agile manifesto is a set of values, not processes. I believe it is
intended to for the most part to gear processes to focus on direct human
interaction.

Spiral, although with perhaps hallmark implementations, is simply a
different method of logistics more amenable to evolutionary projects than
others. It is being taught in schools based on concept and fundamentals,
not implementation - this is the viewpoint I was taking on it.

You can use a method such as a Spiral method and focus on non-human
interaction or human interaction - both would be considered an Spiral
implementation. The latter would likely be measured as being "Agile"

Then again, here we are with terms:

Spiral -
1) fundamental process methodology as now being taught as one process method
(process methodological precepts named Spiral)
2) a particular implementation or operational description reflecting
original introduction of the use of the process.

Agility -
1) minimal process overhead required for organized and manageable
development of software measured uniquely for every organization, product
and/or project.
2) logistics/operations of a process implement would be regarded as having
underlying values matching the Agile Manifesto or closer to matching it than
what would traditionally be so.
3) <description #1 adorned with description #2> <i.e. XP>

It could be argued that Spiral (or any other evolutionary process) could
have more process overhead than traditional methods.

Mark.

----- Original Message -----
From: "Charlie Poole" <***@pooleconsulting.com>
To: <***@topica.com>
Sent: Saturday, February 14, 2004 12:05 AM
Subject: RE: [AM] The Spiral Model
Post by Charlie Poole
Having read the question and ensuing answers I'm struck that nobody has
Agile methods deal with people and how they work together. Historically,
this has been
"out of scope" for software development methodologies. If we compare
approaches while
abstracting away this important difference, they may appear similar, just as
an auto
is like a wagon if you abstract away the source of motive power.
When we choose to abstract away people in our discussion, we are being
non-agile ourselves.
Charlie Poole
www.pooleconsulting.com
www.charliepoole.org
Post by Steven Gordon
-----Original Message-----
Sent: Thursday, February 12, 2004 1:14 PM
Subject: [AM] The Spiral Model
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer
What is the main differences between the spiral model's concepts and the
core of the agile methodologies???
i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?
pls help
i would welcome any comment you could have about this matter...
thanks in advance
Guillermo Camilo
www.lanoosfera.com
www.oolanoosfera.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
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
--^----------------------------------------------------------------
Charlie Poole
2004-02-15 19:17:54 UTC
Permalink
Mark,

I can't disagree with anything you say here... it seemed to me that the
discussion was focusing on comparing the logistics aspect of agile ( your #1
below ) to the Spiral model. That makes some sense since it's what they have
in common. It's also what most academic discussions seem to focus on - for
the same reason.

The only problem with this approach is that it makes the comparison by
ignoring the very strength of the agile approaches. It's only /because/ of
the values that we can strip away so much process overhead and still be
successful. That's where a simple comparison of logistic approaches seems to
me to fall a bit short.

Nevertheless an interesting comparison.

Charlie
Post by Steven Gordon
-----Original Message-----
Sent: Saturday, February 14, 2004 5:50 PM
Subject: Re: [AM] The Spiral Model
The Agile manifesto is a set of values, not processes. I believe it is
intended to for the most part to gear processes to focus on direct human
interaction.
Spiral, although with perhaps hallmark implementations, is simply a
different method of logistics more amenable to evolutionary projects than
others. It is being taught in schools based on concept and fundamentals,
not implementation - this is the viewpoint I was taking on it.
You can use a method such as a Spiral method and focus on non-human
interaction or human interaction - both would be considered an Spiral
implementation. The latter would likely be measured as being "Agile"
Spiral -
1) fundamental process methodology as now being taught as one
process method
(process methodological precepts named Spiral)
2) a particular implementation or operational description reflecting
original introduction of the use of the process.
Agility -
1) minimal process overhead required for organized and manageable
development of software measured uniquely for every organization, product
and/or project.
2) logistics/operations of a process implement would be regarded as having
underlying values matching the Agile Manifesto or closer to
matching it than
what would traditionally be so.
3) <description #1 adorned with description #2> <i.e. XP>
It could be argued that Spiral (or any other evolutionary process) could
have more process overhead than traditional methods.
Mark.
----- Original Message -----
Sent: Saturday, February 14, 2004 12:05 AM
Subject: RE: [AM] The Spiral Model
Post by Charlie Poole
Having read the question and ensuing answers I'm struck that nobody has
Agile methods deal with people and how they work together. Historically,
this has been
"out of scope" for software development methodologies. If we compare
approaches while
abstracting away this important difference, they may appear
similar, just
as
Post by Charlie Poole
an auto
is like a wagon if you abstract away the source of motive power.
When we choose to abstract away people in our discussion, we are being
non-agile ourselves.
Charlie Poole
www.pooleconsulting.com
www.charliepoole.org
Post by Steven Gordon
-----Original Message-----
Sent: Thursday, February 12, 2004 1:14 PM
Subject: [AM] The Spiral Model
hi everybody
after a list of readings about this subject , the spiral model for software
developer (of dr Barry Boehm), i got one question
i hope, despite, you maybe found it obvious, all of you, wouldn't bother to
help me to find the answer
What is the main differences between the spiral model's
concepts and the
Post by Charlie Poole
Post by Steven Gordon
core of the agile methodologies???
i see both of them are , in essence, iterative and incremental, so. how are
we going to differentiate them?
pls help
i would welcome any comment you could have about this matter...
thanks in advance
Guillermo Camilo
www.lanoosfera.com
www.oolanoosfera.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
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
2004-02-15 06:11:32 UTC
Permalink
Mark,

Yes, if we want to build good software, we must
- think about what the software should do
- think about how we can make the software do what it should
- create the software
- make sure that the software does what it is supposed to do

In my mind, the problem with waterfall (mini, maxi, or in between) is an implication that each of these activities should be done in isolation and in the above order.

Agile approaches (at least, XP) are more holistic in that these activities can be done in any order, and even simultaneously. I am not sure what Scott might mean by the Spiral model not being "realistic" or "accurate", but I do believe replacing the mini-waterfalls in Spiral with a holistic, integrated form of software development would make it more effective.

Steven Gordon

-----Original Message-----
From: Mark Graybill [mailto:***@Graybill.com]
Sent: Sat 2/14/2004 7:03 PM
To: ***@topica.com
Cc:
Subject: Re: [AM] The Spiral Model

<snip>

I remember a rather silly discussion here about mini-waterfalls. To avoid a
similar discussion resulting from a comment here, is that there are certain
activities unavoidable in good software development.

1. Conceptualize what will be done such as the design or the test in TDD, or
scribbles on paper before something is coded - or at least the thought
paths - or thought then code cycles that occur during the conceptualization
of what is coded.
2. Something is coded.
3. The code is verified, either by planning or by operational use (e.g.
customer says it doesn't do what he said it should do.)

One therefore could argue that this is design, code, test, or a
mini-waterfall.

<snip>

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
--^----------------------------------------------------------------
Scott E. Preece
2004-02-16 15:44:20 UTC
Permalink
Your comments assume that "process overhead" is the major problem that
agile methods overcome and that "valuing people" is the major reason why
agile methods succeed.

I have to be curmudgeonly again and point out that we generally don't
have a lot of evidence as to which factors have the greatest impact on
agility, even taking as a given that they are generally successful.

My own opinion is that it is the iteration, high customer involvement,
and rapid feedback that are the big wins (the primary sources of
agility) and that the "process overhead" argument is largely a red
herring. The real process issue is whether the defined process is
iterative and incremental, rather than whether it is well-defined.

Of course, I also don't think that "valuing people" is unique to the
agile methods. Effective organizations, whatever their process, trust
and respect their people.

I thought it was interesting that the Feature-Driven Development book
claims that it concentrates only on the "construction" phases, not on
the front end, because the construction phases are the hard part. In my
organization I would say exactly the opposite was true - we don't have
much trouble building stuff, we have tons of trouble deciding what to
build.

So, I tend to value the notion of feedback-driven direct commitment,
rather than things like avoiding documentation and inspections. I think
the "process overhead" is in-the-noise, compared with the benefits of
having the customer seeing what you're doing and buying in day-by-day.

scott

| From: Charlie Poole<***@pooleconsulting.com>
| Date: Sun, 15 Feb 2004 11:17:54 -0800
|
| Mark,
|
| I can't disagree with anything you say here... it seemed to me that the
| discussion was focusing on comparing the logistics aspect of agile ( your #1
| below ) to the Spiral model. That makes some sense since it's what they have
| in common. It's also what most academic discussions seem to focus on - for
| the same reason.
|
| The only problem with this approach is that it makes the comparison by
| ignoring the very strength of the agile approaches. It's only /because/ of
| the values that we can strip away so much process overhead and still be
| successful. That's where a simple comparison of logistic approaches seems to
| me to fall a bit short.
|
| Nevertheless an interesting comparison.
|
| Charlie
|
|
| > -----Original Message-----
| > From: Mark Graybill [mailto:***@Graybill.com]
| > Sent: Saturday, February 14, 2004 5:50 PM
| > To: ***@topica.com
| > Subject: Re: [AM] The Spiral Model
| >
| >
| > The Agile manifesto is a set of values, not processes. I believe it is
| > intended to for the most part to gear processes to focus on direct human
| > interaction.
| >
| > Spiral, although with perhaps hallmark implementations, is simply a
| > different method of logistics more amenable to evolutionary projects than
| > others. It is being taught in schools based on concept and fundamentals,
| > not implementation - this is the viewpoint I was taking on it.
| >
| > You can use a method such as a Spiral method and focus on non-human
| > interaction or human interaction - both would be considered an Spiral
| > implementation. The latter would likely be measured as being "Agile"
| >
| > Then again, here we are with terms:
| >
| > Spiral -
| > 1) fundamental process methodology as now being taught as one
| > process method
| > (process methodological precepts named Spiral)
| > 2) a particular implementation or operational description reflecting
| > original introduction of the use of the process.
| >
| > Agility -
| > 1) minimal process overhead required for organized and manageable
| > development of software measured uniquely for every organization, product
| > and/or project.
| > 2) logistics/operations of a process implement would be regarded as having
| > underlying values matching the Agile Manifesto or closer to
| > matching it than
| > what would traditionally be so.
| > 3) <description #1 adorned with description #2> <i.e. XP>
| >
| > It could be argued that Spiral (or any other evolutionary process) could
| > have more process overhead than traditional methods.
| >
| > Mark.
| >
| > ----- Original Message -----
| > From: "Charlie Poole" <***@pooleconsulting.com>
| > To: <***@topica.com>
| > Sent: Saturday, February 14, 2004 12:05 AM
| > Subject: RE: [AM] The Spiral Model
| >
| >
| > > Having read the question and ensuing answers I'm struck that nobody has
| > > mentioned this:
| > >
| > > Agile methods deal with people and how they work together. Historically,
| > > this has been
| > > "out of scope" for software development methodologies. If we compare
| > > approaches while
| > > abstracting away this important difference, they may appear
| > similar, just
| > as
| > > an auto
| > > is like a wagon if you abstract away the source of motive power.
| > >
| > > When we choose to abstract away people in our discussion, we are being
| > > non-agile ourselves.
| > >
| > > Charlie Poole
| > > ***@pooleconsulting.com
| > > www.pooleconsulting.com
| > > www.charliepoole.org
| > >
| > >
| > >
| > >
| > >
| > > > -----Original Message-----
| > > > From: guillermo camilo [mailto:***@unsa.edu.pe]
| > > > Sent: Thursday, February 12, 2004 1:14 PM
| > > > To: ***@topica.com
| > > > Cc: chicago-agile-***@yahoogroups.com; ***@yahoogroups.com;
| > > > ***@yahoogroups.com
| > > > Subject: [AM] The Spiral Model
| > > >
| > > >
| > > > hi everybody
| > > > after a list of readings about this subject , the spiral model
| > > > for software
| > > > developer (of dr Barry Boehm), i got one question
| > > > i hope, despite, you maybe found it obvious, all of you, wouldn't
| > > > bother to
| > > > help me to find the answer
| > > >
| > > > What is the main differences between the spiral model's
| > concepts and the
| > > > core of the agile methodologies???
| > > >
| > > > i see both of them are , in essence, iterative and incremental,
| > > > so. how are
| > > > we going to differentiate them?
| > > >
| > > > pls help
| > > > i would welcome any comment you could have about this matter...
| > > > thanks in advance
| > > >
| > > > Guillermo Camilo
| > > > ***@unsa.edu.pe
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: 217-384-8550
phone: 217-384-8589 cell: 217-433-6114 pager: ***@msg.myvzw.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
--^----------------------------------------------------------------
Charlie Poole
2004-02-16 18:03:14 UTC
Permalink
Scott,

Actually, my comments merely assume the existence of the statements on
process overhead in the post I was responding to. ;-)

My own assumption is that projects succeed by enabling the people who
work on them to know and do what is needed for that success. Different
methodologies might contribute to that characteristic or detract from
it. In fact, different instances of the same methodology might have
opposite effects.

"Valuing people" is IMO agile shorthand for the above. Although much of
management literature over the years has addressed the need to do this,
AFAIK the software development approaches collectively known as agile
seem to be the first to actually talk about it out loud.

I agree that this says nothing about weight of process in and of itself.
However, my personal experience leads me to think that projects run in a
way that enables folks to know and carry out the tasks needed tend to
need less overhead than those that rely on telling them what tasks to do
and how to do them. If that observation is correct, one of the reasons -
there are of course others - for needing a relatively heavier amount of
up front requirements and design documentation in certain projects can
be set aside.

Charlie Poole
Post by Steven Gordon
-----Original Message-----
Sent: Monday, February 16, 2004 7:44 AM
Subject: Re: [AM] The Spiral Model
Your comments assume that "process overhead" is the major
problem that agile methods overcome and that "valuing people"
is the major reason why agile methods succeed.
I have to be curmudgeonly again and point out that we
generally don't have a lot of evidence as to which factors
have the greatest impact on agility, even taking as a given
that they are generally successful.
My own opinion is that it is the iteration, high customer
involvement, and rapid feedback that are the big wins (the
primary sources of
agility) and that the "process overhead" argument is largely
a red herring. The real process issue is whether the defined
process is iterative and incremental, rather than whether it
is well-defined.
Of course, I also don't think that "valuing people" is unique
to the agile methods. Effective organizations, whatever
their process, trust and respect their people.
I thought it was interesting that the Feature-Driven
Development book claims that it concentrates only on the
"construction" phases, not on the front end, because the
construction phases are the hard part. In my organization I
would say exactly the opposite was true - we don't have much
trouble building stuff, we have tons of trouble deciding what
to build.
So, I tend to value the notion of feedback-driven direct
commitment, rather than things like avoiding documentation
and inspections. I think the "process overhead" is
in-the-noise, compared with the benefits of having the
customer seeing what you're doing and buying in day-by-day.
scott
| Date: Sun, 15 Feb 2004 11:17:54 -0800
|
| Mark,
|
| I can't disagree with anything you say here... it seemed to me that
| the discussion was focusing on comparing the logistics
aspect of agile
| ( your #1 below ) to the Spiral model. That makes some sense since
| it's what they have in common. It's also what most academic
| discussions seem to focus on - for the same reason.
|
| The only problem with this approach is that it makes the
comparison by
| ignoring the very strength of the agile approaches. It's only
| /because/ of the values that we can strip away so much process
| overhead and still be successful. That's where a simple
comparison of
| logistic approaches seems to me to fall a bit short.
|
| Nevertheless an interesting comparison.
|
| Charlie
|
|
| > -----Original Message-----
| > Sent: Saturday, February 14, 2004 5:50 PM
| > Subject: Re: [AM] The Spiral Model
| >
| >
| > The Agile manifesto is a set of values, not processes. I
believe it
| > is intended to for the most part to gear processes to focus on
| > direct human interaction.
| >
| > Spiral, although with perhaps hallmark implementations,
is simply a
| > different method of logistics more amenable to
evolutionary projects
| > than others. It is being taught in schools based on concept and
| > fundamentals, not implementation - this is the viewpoint I was
| > taking on it.
| >
| > You can use a method such as a Spiral method and focus on
non-human
| > interaction or human interaction - both would be considered an
| > Spiral implementation. The latter would likely be
measured as being
| > "Agile"
| >
| >
| > Spiral -
| > 1) fundamental process methodology as now being taught as one
| > process method (process methodological precepts named Spiral)
| > 2) a particular implementation or operational description
reflecting
| > original introduction of the use of the process.
| >
| > Agility -
| > 1) minimal process overhead required for organized and manageable
| > development of software measured uniquely for every organization,
| > product and/or project.
| > 2) logistics/operations of a process implement would be
regarded as
| > having underlying values matching the Agile Manifesto or
closer to
| > matching it than what would traditionally be so.
| > 3) <description #1 adorned with description #2> <i.e. XP>
| >
| > It could be argued that Spiral (or any other evolutionary
process)
| > could have more process overhead than traditional methods.
| >
| > Mark.
| >
| > ----- Original Message -----
| > Sent: Saturday, February 14, 2004 12:05 AM
| > Subject: RE: [AM] The Spiral Model
| >
| >
| > > Having read the question and ensuing answers I'm struck that
| > >
| > > Agile methods deal with people and how they work together.
| > > Historically, this has been "out of scope" for software
| > > development methodologies. If we compare approaches while
| > > abstracting away this important difference, they may appear
| > similar, just
| > as
| > > an auto
| > > is like a wagon if you abstract away the source of motive power.
| > >
| > > When we choose to abstract away people in our
discussion, we are
| > > being non-agile ourselves.
| > >
| > > Charlie Poole
| > > www.pooleconsulting.com
| > > www.charliepoole.org
| > >
| > >
| > >
| > >
| > >
| > > > -----Original Message-----
| > > > Sent: Thursday, February 12, 2004 1:14 PM
| > > > Subject: [AM] The Spiral Model
| > > >
| > > >
| > > > hi everybody
| > > > after a list of readings about this subject , the
spiral model
| > > > for software developer (of dr Barry Boehm), i got one question
| > > > i hope, despite, you maybe found it obvious, all of
you, wouldn't
| > > > bother to
| > > > help me to find the answer
| > > >
| > > > What is the main differences between the spiral model's
| > concepts and the
| > > > core of the agile methodologies???
| > > >
| > > > i see both of them are , in essence, iterative and
incremental,
| > > > so. how are we going to differentiate them?
| > > >
| > > > pls help
| > > > i would welcome any comment you could have about this
matter...
| > > > thanks in advance
| > > >
| > > > Guillermo Camilo
--
scott preece
motorola urbana design center (il67), 1800 s. oak st.,
champaign, il 61820
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
--^----------------------------------------------------------------
Scott E. Preece
2004-02-16 18:35:28 UTC
Permalink
Well, the SEI publishes a "People CMM" that specifically evaluates
organizations on how well mature their people processes are, including
things like communications, training, workspace, etc.

For that matter, I suspect the Software CMM authors would say that their
goals are EXACTLY "enabling the people... to know and to do what is
needed for success." Many of the CMM goals are are directly focused on
things like making sure information about changes gets to the people who
need to know them and on people knowing what they need to know to get
their jobs done.

For that matter, PeopleWare was published about 15 years ago, so
I'm not sure where you think there has been silence.

scott

| From: Charlie Poole<***@pooleconsulting.com>
|
| Actually, my comments merely assume the existence of the statements on
| process overhead in the post I was responding to. ;-)
|
| My own assumption is that projects succeed by enabling the people who
| work on them to know and do what is needed for that success. Different
| methodologies might contribute to that characteristic or detract from
| it. In fact, different instances of the same methodology might have
| opposite effects.
|
| "Valuing people" is IMO agile shorthand for the above. Although much of
| management literature over the years has addressed the need to do this,
| AFAIK the software development approaches collectively known as agile
| seem to be the first to actually talk about it out loud.
|
| I agree that this says nothing about weight of process in and of itself.
| However, my personal experience leads me to think that projects run in a
| way that enables folks to know and carry out the tasks needed tend to
| need less overhead than those that rely on telling them what tasks to do
| and how to do them. If that observation is correct, one of the reasons -
| there are of course others - for needing a relatively heavier amount of
| up front requirements and design documentation in certain projects can
| be set aside.
|
| Charlie Poole
| ***@pooleconsulting.com
|
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: 217-384-8550
phone: 217-384-8589 cell: 217-433-6114 pager: ***@msg.myvzw.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
--^----------------------------------------------------------------
Charlie Poole
2004-02-16 19:08:07 UTC
Permalink
Scott,

I've been in organizations that follow all the recommended practices for
dealing with people. It's not the same thing as valuing and enabling.
And PeopleWare was almost entirely ignored for a long time.

I suspect that we can't agree on what it means to truly enable a group
of people to work. That's in part because I barely know how to define it
myself - although I know it when I see it, and I definitely know when
it's not there. It may also be that you have been incredibly lucky in
the environments in which you have found yourself. :-)

Charlie Poole
Post by Steven Gordon
-----Original Message-----
Sent: Monday, February 16, 2004 10:35 AM
Subject: Re: [AM] The Spiral Model
Well, the SEI publishes a "People CMM" that specifically
evaluates organizations on how well mature their people
processes are, including things like communications,
training, workspace, etc.
For that matter, I suspect the Software CMM authors would say
that their goals are EXACTLY "enabling the people... to know
and to do what is needed for success." Many of the CMM goals
are are directly focused on things like making sure
information about changes gets to the people who need to know
them and on people knowing what they need to know to get
their jobs done.
For that matter, PeopleWare was published about 15 years ago,
so I'm not sure where you think there has been silence.
scott
|
| Actually, my comments merely assume the existence of the
statements on
| process overhead in the post I was responding to. ;-)
|
| My own assumption is that projects succeed by enabling the
people who
| work on them to know and do what is needed for that
success. Different
| methodologies might contribute to that characteristic or
detract from
| it. In fact, different instances of the same methodology might have
| opposite effects.
|
| "Valuing people" is IMO agile shorthand for the above.
Although much
| of management literature over the years has addressed the
need to do
| this, AFAIK the software development approaches
collectively known as
| agile seem to be the first to actually talk about it out loud.
|
| I agree that this says nothing about weight of process in and of
| itself. However, my personal experience leads me to think that
| projects run in a way that enables folks to know and carry out the
| tasks needed tend to need less overhead than those that rely on
| telling them what tasks to do and how to do them. If that
observation
| is correct, one of the reasons - there are of course others - for
| needing a relatively heavier amount of up front requirements and
| design documentation in certain projects can be set aside.
|
| Charlie Poole
|
--
scott preece
motorola urbana design center (il67), 1800 s. oak st.,
champaign, il 61820
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
--^----------------------------------------------------------------
Philippe Back (High Octane)
2004-02-17 09:24:17 UTC
Permalink
Maybe is there no other way than the old:

forming-->storming-->norming-->performing evolution where :

case1 : people stay at the "forming" level because storming will make them
look bad, remove some privileges, feel too uncomfortable etc

case2: people never exit "storming" and keep arguing, producing nothing

case3: people enter "norming" and produce endless procedures and books etc,
ending up losing credibility

case4: people are in the "performing" state and are able to do to what they
are good at in good conditions. Usually a state where the mass of the
case1,2 and 3 people will bring them down if the organization is big.

So, maybe being in a good team doing cool stuff means working "with
agility", "in the small"
because that's what human beings are able to do properly given their
cognitive and relational abilities.

So, either Command & Control for big groups or Meritocracy for smaller
ones...
And everything in between of course... ;-)

/Philippe Back
www.highoctane.be

----- Original Message -----
From: "Charlie Poole" <***@pooleconsulting.com>
To: <***@topica.com>
Sent: Monday, 16 February, 2004 20:08
Subject: RE: [AM] The Spiral Model
Post by Charlie Poole
Scott,
I've been in organizations that follow all the recommended practices for
dealing with people. It's not the same thing as valuing and enabling.
And PeopleWare was almost entirely ignored for a long time.
I suspect that we can't agree on what it means to truly enable a group
of people to work. That's in part because I barely know how to define it
myself - although I know it when I see it, and I definitely know when
it's not there. It may also be that you have been incredibly lucky in
the environments in which you have found yourself. :-)
Charlie Poole
Post by Steven Gordon
-----Original Message-----
Sent: Monday, February 16, 2004 10:35 AM
Subject: Re: [AM] The Spiral Model
Well, the SEI publishes a "People CMM" that specifically
evaluates organizations on how well mature their people
processes are, including things like communications,
training, workspace, etc.
For that matter, I suspect the Software CMM authors would say
that their goals are EXACTLY "enabling the people... to know
and to do what is needed for success." Many of the CMM goals
are are directly focused on things like making sure
information about changes gets to the people who need to know
them and on people knowing what they need to know to get
their jobs done.
For that matter, PeopleWare was published about 15 years ago,
so I'm not sure where you think there has been silence.
scott
|
| Actually, my comments merely assume the existence of the
statements on
| process overhead in the post I was responding to. ;-)
|
| My own assumption is that projects succeed by enabling the
people who
| work on them to know and do what is needed for that
success. Different
| methodologies might contribute to that characteristic or
detract from
| it. In fact, different instances of the same methodology might have
| opposite effects.
|
| "Valuing people" is IMO agile shorthand for the above.
Although much
| of management literature over the years has addressed the
need to do
| this, AFAIK the software development approaches
collectively known as
| agile seem to be the first to actually talk about it out loud.
|
| I agree that this says nothing about weight of process in and of
| itself. However, my personal experience leads me to think that
| projects run in a way that enables folks to know and carry out the
| tasks needed tend to need less overhead than those that rely on
| telling them what tasks to do and how to do them. If that
observation
| is correct, one of the reasons - there are of course others - for
| needing a relatively heavier amount of up front requirements and
| design documentation in certain projects can be set aside.
|
| Charlie Poole
|
--
scott preece
motorola urbana design center (il67), 1800 s. oak st.,
champaign, il 61820
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
--^----------------------------------------------------------------
Loading...