Call for participation: What types of organisations adopt agile methods?
Ant Grinyer
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:
Your participation is greatly appreciated.
Kindest Regards
Ant Grinyer
----------
Business Analyst | Cegedim Pharmaceutical Solutions, UK
PhD Candidate | The Open University | Milton Keynes, UK
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.
--
James Kanze (GABI Software) email:james...@gmail.com
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
Lew
>> 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.
> "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.
> 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.
> 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.
Like any such thing, of course, there is an awful lot of B.S. around "agile"
and other methodologies. That doesn't make James Kanze's revisionist
definitions any more accurate.
--
Lew
Patricia Shanahan
> 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.
Patricia
Tom Anderson
> On Jul 10, 11:33 pm, a.grin...@sky.com (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
James Kanze
> (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
> On Fri, 11 Jul 2008, James Kanze wrote:
> > On Jul 10, 11:33 pm, a.grin...@sky.com (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
In other words, they're being agile:-).
con...@lewscanon.com
> On Jul 11, 3:00 pm, Tom Anderson <t...@urchin.earth.li> wrote:
>
> > On Fri, 11 Jul 2008, James Kanze wrote:
> > > On Jul 10, 11:33 pm, a.grin...@sky.com (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
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
> > On Jul 11, 3:00 pm, Tom Anderson <t...@urchin.earth.li> wrote:
> > > On Fri, 11 Jul 2008, James Kanze wrote:
> > > > On Jul 10, 11:33 pm, a.grin...@sky.com (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.
Timo Geusch
> On Jul 11, 6:43 pm, con...@lewscanon.com wrote:
>> 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.
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.
con...@lewscanon.com
> >> 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.
James Kanze writes:
> > 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.
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.
Timo Geusch wrote:
> 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,
--
Lew
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.)
>
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!
--
Ian Collins.