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

[Ant Grinyer]

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/Pub...439004E6A1F?OpenDocument&subsection=computing


Your participation is greatly appreciated.
Kindest Regards
Ant Grinyer

 

[James Kanze]

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.

 

[Tom Anderson]

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

 

[James Kanze]

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.

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).

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

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.

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]

[...]

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.)

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]

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.

 

[conrad]

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.

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.

 

[James Kanze]

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.

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.

 

[Timo Geusch]

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.

I'm pretty sure Steve McConnell mentioned it in the first edition of
Code Complete back in the early/mid nineties. Unfortunately I've since
replaced it with the second edition so I can't verify this.

 

[conrad]

Have you considered googling for it?

/Wicked Problems, Righteous Solutions/ gives a good overview of all
the software-development methodologies extant in the mid-nineties,
with a thorough analysis of their strengths and weaknesses. It
predates "XP" and "agile".

<http://www.google.com/search?q="Wicked+Problems%2C+Righteous
+Solutions">

Other references: GIYF.

I am a reference, because my comments were based on my own personal
work experience. Shops where I worked in 1980-1981 practiced
waterfall development, ostensibly, and called it by that name.

I'm pretty sure Steve McConnell mentioned it in the first edition of
Code Complete back in the early/mid nineties. Unfortunately I've since
replaced it with the second edition so I can't verify this.

GIYF, James Kanze,

 

[Ian Collins]

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.)

Oh come on James, that's just not true. I have a number of XP developed
embedded products in the wild and by any measure the company uses, they
are the most robust products the company has ever shipped. Our main
measure was the only one that matters to our customers, defect reports.
The number has been vanishingly small, a small fraction of the number
for the previous generation controllers.

If you are an XP team supporting a buggy product, your most important
and visible measure - velocity will suffer.

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.

Now here we agree!