Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Call for participation: What types of organisations adopt agile methods?

Reply
Thread Tools

Call for participation: What types of organisations adopt agile methods?

 
 
Ant Grinyer
Guest
Posts: n/a
 
      07-10-2008
Having worked in software development for over 15 years in many
organisations using different development methodologies such as
waterfall, RUP, Scrum and XP, I'm still not sure if there is a
specific 'type' of organisation that is more likely to adopt agile
approaches than others?

I guess it could be argued that those organisations that are more
innovative or open to change are more likely to adopt agile methods?

To try and gain more understanding, and because I have a passion for
software development methodologies, I started a PhD five years ago
(part-time) to look at this issue. I'm now at the point where I'm
conducting a short survey to determine what factors might or might not
influence the adoption of agile methods, in the hope to provide some
enlightenment. If we get enough participation, I then hope to report
this back to the group to see if there are indeed any trends.

The survey is short and should take around 5 - 10 minutes to complete,
so please bare with the scaled questions whereby you are asked to rate
your agreement against a list of statements. To participate, could I
kindly ask you to fill in the survey using the link below -

http://ou1211237011.agile-adoption.sgizmo.com

I believe if we can determine the characteristics of organisations
that adopt and do not adopt agile methods, we can get a better
understanding whether certain organisations are more conducive to
adopting agile methods?

Note this is NOT a marketing survey and is used for doctoral and
practitioner research purposes. All findings and results will be
published to the group and responses treated in strict confidence.
Evidence of my research can be found here:

http://www.computing.open.ac.uk/Publ...tion=computing


Your participation is greatly appreciated.
Kindest Regards
Ant Grinyer
----------
Business Analyst | Cegedim Pharmaceutical Solutions, UK
PhD Candidate | The Open University | Milton Keynes, UK
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:
> Having worked in software development for over 15 years in
> many organisations using different development methodologies
> such as waterfall, RUP, Scrum and XP, I'm still not sure if
> there is a specific 'type' of organisation that is more likely
> to adopt agile approaches than others?


> I guess it could be argued that those organisations that are
> more innovative or open to change are more likely to adopt
> agile methods?


It could just as easily be argued that those organisations care
less about quality and robustness. Or don't have to worry about
a budget. Or are easily taken in by fancy advertising words,
rather than substance.

"Agile programming", as such, doesn't mean anything. It's just
a positive sounding buzz word, which anyone developing a new
methodology applies to make it sound good.

Note that the expression "waterfall methodology" doesn't apply
to any definite methodology either. It's just the opposite of
agile programming, a negative sounding buzz word to apply to
those who don't buy into your new methodology.

Neither correspond to any single, well defined methodology.
Roughly speaking: if I do it, it's agile programming, but if
someone else does it, it's waterfall.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      07-11-2008
"James Kanze" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:
> Having worked in software development for over 15 years in
> many organisations using different development methodologies
> such as waterfall, RUP, Scrum and XP, I'm still not sure if
> there is a specific 'type' of organisation that is more likely
> to adopt agile approaches than others?


> I guess it could be argued that those organisations that are
> more innovative or open to change are more likely to adopt
> agile methods?


It could just as easily be argued that those organisations care
less about quality and robustness. Or don't have to worry about
a budget. Or are easily taken in by fancy advertising words,
rather than substance.

"Agile programming", as such, doesn't mean anything. It's just
a positive sounding buzz word, which anyone developing a new
methodology applies to make it sound good.

Note that the expression "waterfall methodology" doesn't apply
to any definite methodology either. It's just the opposite of
agile programming, a negative sounding buzz word to apply to
those who don't buy into your new methodology.

Neither correspond to any single, well defined methodology.
Roughly speaking: if I do it, it's agile programming, but if
someone else does it, it's waterfall.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

********************************************

I'd also argue that in a number of situations the waterfall model is either
just as acceptable as any other, or even to be preferred. Waterfall
methodology does mean something specific: the purely sequential model.

By and large, in situations where I've seen the sequential model struggle or
fail, it's because the organisation was incompetent at gathering
requirements and/or not able to resist pressure (both external or internal)
to change requirements during the process. This is frequently accompanied by
a lack of discipline, and usually pretty lackluster software development
processes overall - makes one wonder if the sequential model isn't
frequently blamed by organizations that couldn't successfully develop with
*any* model.

Software developers do (or should) use the sequential process fairly
frequently. For example, if a client gave you a clear set of requirements
for a project that is going to require a man-month or less (for sake of
example) I'd be hard-pressed to argue that this project would require
something other than purely sequential. Go ahead and use something else if
you like - just don't tell me that sequential wouldn't work.

For a bigger project - maybe in particular some of the biggest projects -
the sequential model could well be advisable. Some of the criticisms of the
process are valid, such as some implementation details may not become known
until coding time (as in, "none of these bleeding-edge technologies actually
work"), or it may be very difficult to resist client demands for
requirements changes. However, a lot of the time the criticisms of pure
sequential boil down to this: less-than-excellent organizations find it
difficult to do. Or to put it another way, if your organization is mediocre,
go for a methodology that tolerates mediocrity more robustly.

Call me cynical.

AHS


 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      07-11-2008
On Fri, 11 Jul 2008, James Kanze wrote:

> On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:
>
>> Having worked in software development for over 15 years in
>> many organisations using different development methodologies
>> such as waterfall, RUP, Scrum and XP, I'm still not sure if
>> there is a specific 'type' of organisation that is more likely
>> to adopt agile approaches than others?

>
>> I guess it could be argued that those organisations that are
>> more innovative or open to change are more likely to adopt
>> agile methods?

>
> It could just as easily be argued that those organisations care
> less about quality and robustness. Or don't have to worry about
> a budget. Or are easily taken in by fancy advertising words,
> rather than substance.
>
> "Agile programming", as such, doesn't mean anything. It's just a
> positive sounding buzz word, which anyone developing a new methodology
> applies to make it sound good.


No, agile has a very well-defined meaning. It's what used to be called
Extreme Programming, which is based on a set of commandments recorded by
St Kent of Beck. They had to change the name because it was putting people
off.

And if you think that agile produces software of lower quality and
robustness than traditional methods, i think you need to lay off the
mushrooms for a bit.

> Neither correspond to any single, well defined methodology. Roughly
> speaking: if I do it, it's agile programming, but if someone else does
> it, it's waterfall.


You may be quite right about people using 'agile' as a buzzword to mean
anything and nothing, but that's a misuse of the term.

tom

--
20 Minutes into the Future
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      07-11-2008
On Fri, 11 Jul 2008, Arved Sandstrom wrote:

> By and large, in situations where I've seen the sequential model
> struggle or fail, it's because the organisation was incompetent at
> gathering requirements and/or not able to resist pressure (both external
> or internal) to change requirements during the process.


Absolutely. Changing requirements is what kills waterfall. And the problem
is that *that happens*. Gathering perfect requirements upfront is
spectacularly hard, and often probably entirely impossible, because it
involves an understanding of how the system will interact with existing
products and processes that can't be determined without actually seeing
it. On top of that, the client's needs may genuinely change during the
liftime of the project.

Okay, so maybe you could put enough time, energy and intelligence into
requirements gathering that you could apply waterfall. But why not just
adopt a methodology that doesn't require you to do that? Using agile means
that you can easily adapt to changes in requirements, so you can just
forget all that up-front stuff.

> This is frequently accompanied by a lack of discipline, and usually
> pretty lackluster software development processes overall - makes one
> wonder if the sequential model isn't frequently blamed by organizations
> that couldn't successfully develop with *any* model.


This strikes me as very likely to be true.

There's an old XP get-out here, though, which is to say that in these
cases, the developers aren't truly following XP. Doing XP means, amongst
other things, having unit tests for everything, keeping the system
well-factored, and sticking religiously to implementing fine-grained,
well-defined requirements. If you do that, it works, and you *will*
deliver good software. If you don't, it doesn't - but then you aren't
*really* doing XP.

> Software developers do (or should) use the sequential process fairly
> frequently. For example, if a client gave you a clear set of
> requirements for a project that is going to require a man-month or less
> (for sake of example) I'd be hard-pressed to argue that this project
> would require something other than purely sequential. Go ahead and use
> something else if you like - just don't tell me that sequential wouldn't
> work.


Agreed. In fact, for a project of that scale, agile and waterfall become
largely degenerate, and both involve doing much the same things. Capture
the requirements, figure out how to test it, write the code.

The difference only emerges on longer projects - waterfall stretches each
phase to be longer, agile keeps the same phase length, and splits the
project into iterations.

> For a bigger project - maybe in particular some of the biggest projects
> - the sequential model could well be advisable. Some of the criticisms
> of the process are valid, such as some implementation details may not
> become known until coding time (as in, "none of these bleeding-edge
> technologies actually work"), or it may be very difficult to resist
> client demands for requirements changes. However, a lot of the time the
> criticisms of pure sequential boil down to this: less-than-excellent
> organizations find it difficult to do.


Exactly. That's the whole point! The vast majority of organisations are
less than excellent, by definition, so a methodology that requires heroic
geniuses to work isn't very useful in the real world.

> Or to put it another way, if your organization is mediocre, go for a
> methodology that tolerates mediocrity more robustly.


And that's why i work in an agile shop!

tom

--
20 Minutes into the Future
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 11, 1:26 pm, Lew <(E-Mail Removed)> wrote:
> (Ant Grinyer) wrote:
> >> I guess it could be argued that those organisations that are
> >> more innovative or open to change are more likely to adopt
> >> agile methods?

> James Kanze wrote:
> > It could just as easily be argued that those organisations care
> > less about quality and robustness. Or don't have to worry about
> > a budget. Or are easily taken in by fancy advertising words,
> > rather than substance.


> This shows a lack of research into or understanding of what
> the proponents of agile programming are promoting.


Or too much research. Every one I've read is promoting
something different.

> > "Agile programming", as such, doesn't mean anything. It's just
> > a positive sounding buzz word, which anyone developing a new
> > methodology applies to make it sound good.


> Again, you have failed to understand what people are saying.
> "Agile programming" is a rubric for a particular approach to
> software project management.


Yes, the one the particular person using the phrase is
promoting. It's become a Humpty-Dumpty word, like OO (or to a
much less degree, generic programming).

> > Note that the expression "waterfall methodology" doesn't apply
> > to any definite methodology either. It's just the opposite of


> Waterfall has been around for almost fifty years, long enough
> for people to understand that it refers also to a specific set
> of development principles. The term is broad, yes, but not
> just


> > a negative sounding buzz word to apply to
> > those who don't buy into your new methodology.


> In fact, the term "waterfall" for software development
> predates "your new methodology" by decades, so it is more than
> a little disingenuous to blame the agile programming world for
> that term.


Sorry, you're just plain wrong there. Bad development processes
have been around for ages (and are still around), but the only
uses of the term "waterfall methodology" that I've been able to
find have been as strawmen.

I'm not saying that no organization has used what looks like
what the advocates of other methodologies present as
"waterfall". But it's never been described and presented as a
good development methodology. No one has ever "adopted"
waterfall methodology. And of course, some of the techniques
I've seen used by people claiming to be using "agile" methods
have been just as bad.

> > Neither correspond to any single, well defined methodology.
> > Roughly speaking: if I do it, it's agile programming, but if
> > someone else does it, it's waterfall.


> That is inaccurate. For those who want to know, googling will
> reveal the truth.


Yup. It will reveal an incredible number of different
definitions of "agile programming".

As far as the name of a methodology goes, of course, it's pure
advertising. It doesn't really say anything about the
methodology. It's just a positive sounding phrase to suggest
that the methodology has some particular positive
characteristic, and to imply by intuendo that other
methodologies don't. (Program methodologies have been "agile"
since programming began, and arguably, the most agile method
around is that of the "real programmer", the isolated genius who
has everything in his head, and can rewrite all of the code in
no time.)

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 11, 3:00 pm, Tom Anderson <(E-Mail Removed)> wrote:
> On Fri, 11 Jul 2008, James Kanze wrote:
> > On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:


[...]
> > "Agile programming", as such, doesn't mean anything. It's
> > just a positive sounding buzz word, which anyone developing
> > a new methodology applies to make it sound good.


> No, agile has a very well-defined meaning. It's what used to
> be called Extreme Programming, which is based on a set of
> commandments recorded by St Kent of Beck. They had to change
> the name because it was putting people off.


That's one definition. (Not that extreme programming is any
more exact---what it means depend on who you are reading.)

> And if you think that agile produces software of lower quality
> and robustness than traditional methods, i think you need to
> lay off the mushrooms for a bit.


Most of the techniques I've seen associated with it do produce
software with measurably lower quality and robustness than the
best current practice. (But of course, if you're "agile", you
don't take the time to measure, so you don't know this.)

> > Neither correspond to any single, well defined methodology.
> > Roughly speaking: if I do it, it's agile programming, but if
> > someone else does it, it's waterfall.


> You may be quite right about people using 'agile' as a
> buzzword to mean anything and nothing, but that's a misuse of
> the term.


The problem then is that it has been misused so often that it's
lost any real meaning. Or perhaps the real problem is that
people like Kent Beck didn't choose a more descriptive name.
Although I'm not sure that's a fundamental reason. Something
like "software maturity model" also has a very positive buzz,
without really saying anything, but at least at present, I've
only seen it really applied to one particular methodology.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 11, 2:36 pm, Patricia Shanahan <(E-Mail Removed)> wrote:
> Ant Grinyer wrote:
> > Having worked in software development for over 15 years in
> > many organisations using different development methodologies
> > such as waterfall, RUP, Scrum and XP, I'm still not sure if
> > there is a specific 'type' of organisation that is more
> > likely to adopt agile approaches than others?


> > I guess it could be argued that those organisations that are
> > more innovative or open to change are more likely to adopt
> > agile methods?


> Surely the methodology should be chosen to fit the project,
> not fixed for the organization. I know that I use different
> methodologies depending on what I am doing.


> Maybe an organization that does not adopt agile methods is
> just doing a lot of projects they do not suit.


In other words, they're being agile.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
conrad@lewscanon.com
Guest
Posts: n/a
 
      07-11-2008
James Kanze <(E-Mail Removed)> wrote:
> On Jul 11, 3:00 pm, Tom Anderson <(E-Mail Removed)> wrote:
>
> > On Fri, 11 Jul 2008, James Kanze wrote:
> > > On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:


> Most of the techniques I've seen associated with it do produce
> software with measurably lower quality and robustness than the
> best current practice. *(But of course, if you're "agile", you
> don't take the time to measure, so you don't know this.)


This again shows that you really have not taken the time to understand
what the "agile" folks espouse. Measurement and testing are the heart
of the technique. That you say otherwise betrays your ignorance.

As for not seeing the term "waterfall" prior to the promulgation of
the "agile" buzzword, you again show ignorance. I was taught the
"waterfall" method by that name in the late 1970s and early 80s by
people who believe in its efficacy.

>>> Neither correspond to any single, well defined methodology.


Again, for folks who want the truth, don't buy into the nonsense and
straw-man arguments James Kanze presents. Do the research yourself.
GIYF. James Kanze is just trolling.

--
Lew

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 11, 6:43 pm, (E-Mail Removed) wrote:
> James Kanze <(E-Mail Removed)> wrote:
> > On Jul 11, 3:00 pm, Tom Anderson <(E-Mail Removed)> wrote:


> > > On Fri, 11 Jul 2008, James Kanze wrote:
> > > > On Jul 10, 11:33 pm, (E-Mail Removed) (Ant Grinyer) wrote:

> > Most of the techniques I've seen associated with it do produce
> > software with measurably lower quality and robustness than the
> > best current practice. (But of course, if you're "agile", you
> > don't take the time to measure, so you don't know this.)


> This again shows that you really have not taken the time to
> understand what the "agile" folks espouse. Measurement and
> testing are the heart of the technique. That you say
> otherwise betrays your ignorance.


Or maybe that I've read more about it than you have, and thus
have seen the numerous contrasting (and contradictory) claims.
And measurement is certainly NOT part of what Kent Beck
describes.

> As for not seeing the term "waterfall" prior to the promulgation of
> the "agile" buzzword, you again show ignorance. I was taught the
> "waterfall" method by that name in the late 1970s and early 80s by
> people who believe in its efficacy.


Could you cite some references. Because I've talked to a lot of
people, and no one else seems to have ever seen it described,
except to compare their "better" method against.

> >>> Neither correspond to any single, well defined methodology.


> Again, for folks who want the truth, don't buy into the nonsense and
> straw-man arguments James Kanze presents. Do the research yourself.
> GIYF. James Kanze is just trolling.


Well, anyone who looks it up on Google, with an open mind, is
bound to come to the same conclusion I did.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Call for participation: What types of organisations adopt agile methods? Ant Grinyer C++ 10 07-11-2008 08:36 PM
X12::Parser - intent to adopt Erik Hollensbe Perl 2 01-01-2008 05:47 PM
Should I adopt Eclipse RCP? gwlucas07@comcast.net Java 8 05-15-2007 09:26 AM
Hoosier Daddy? Indiana Schools Adopt Linux Au79 Computer Support 0 08-17-2006 06:08 AM
architecture to adopt Vincent RICHOMME C++ 0 12-22-2005 03:12 PM



Advertisments