RE: [AM] The Spiral Model

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
[email protected]

> -----Original Message-----
> From: Scott E. Preece [mailto:[email protected]] 
> Sent: Monday, February 16, 2004 7:44 AM
> To: [email protected]
> 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
> 
> | From: Charlie Poole<[email protected]>
> | 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:[email protected]]
> | > Sent: Saturday, February 14, 2004 5:50 PM
> | > To: [email protected]
> | > 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" <[email protected]>
> | > To: <[email protected]>
> | > 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
> | > > [email protected]
> | > > www.pooleconsulting.com
> | > > www.charliepoole.org
> | > >
> | > >
> | > >
> | > >
> | > >
> | > > > -----Original Message-----
> | > > > From: guillermo camilo [mailto:[email protected]]
> | > > > Sent: Thursday, February 12, 2004 1:14 PM
> | > > > To: [email protected]
> | > > > Cc: [email protected]; [email protected]; 
> | > > > [email protected]
> | > > > 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
> | > > > [email protected]
> 
> -- 
> scott preece
> motorola urbana design center (il67), 1800 s. oak st., 
> champaign, il  61820  
> e-mail:	[email protected]	fax:	217-384-8550
> phone:	217-384-8589	cell: 217-433-6114	pager: 
> [email protected]
> 
> 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: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

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