Re: [AM] The Spiral Model

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" <[email protected]>
To: <[email protected]>
Sent: Monday, 16 February, 2004 20:08
Subject: RE: [AM] The Spiral Model


> 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
> [email protected]
>
> > -----Original Message-----
> > From: Scott E. Preece [mailto:[email protected]]
> > Sent: Monday, February 16, 2004 10:35 AM
> > To: [email protected]
> > 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
> >
> > | From: Charlie Poole<[email protected]>
> > |
> > | 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]
> > |
> >
> > -- 
> > 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
>
>
>

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
--^----------------------------------------------------------------