Agile software development is an iterative, incremental approach to
developing and releasing software. A range of agile methodologies have
emerged and they are based frequent releases, ongoing testing,
customer and stakeholder participation throughout the development
process, co-ownership of code and pair-programming.
iQRA’s Agile Exam will test your knowledge about Agile Development
including XP, and SCRUM techniques in the light of Agile Manifesto
> Agile software development is an iterative, incremental approach to
> developing and releasing software. A range of agile methodologies have
> emerged and they are based frequent releases, ongoing testing,
> customer and stakeholder participation throughout the development
> process, co-ownership of code and pair-programming.
> iQRA’s Agile Exam will test your knowledge about Agile Development
> including XP, and SCRUM techniques in the light of Agile Manifesto
Actually, I feel the same way. But I also see a lot of folks (including management and executives) who feel Agile is the best way to go. And this is in Silicon Valley!
Anyone want to discuss pros and cons of various software development methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid doing it wrong.
> Agile software development is an iterative, incremental approach to
> developing and releasing software. A range of agile methodologies have
I find the term "agile methodologies" to betray an utter lack of understanding.
> emerged and they are based frequent releases, ongoing testing,
That's "based on". Carelessness does not bespeak value.
> customer and stakeholder participation throughout the development
> process, co-ownership of code and pair-programming.
Co-ownership of "pair-programming [sic]"?
> iQRA’s Agile Exam will test your knowledge about Agile Development
> including XP, and SCRUM [sic] techniques in the light of Agile Manifesto
How can anyone so ignorant and ungrammatical develop a valid test of knowledge?
You can't even spell the buzzwords correctly!
Your spam is illiterate, ignorant and unprofessional. I can only conclude that your site is no better. If you're this bad just dating, you'll be worse married.
> Actually, I feel the same way. But I also see a lot of folks (including
> management and executives) who feel Agile is the best way to go. And
> this is in Silicon Valley!
> Anyone want to discuss pros and cons of various software development
> methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid doing
> it wrong.
> Also, new thread, or jack this one?
The subject line is fine for a discussion of agile project management,
so I think hijack it.
First of all, I have seen a general pattern to software development
methodologies:
1. Some people come up with an approach to software development.
2. A lot of books get written, and complete, detailed systems combining
many ideas are produced.
3. The detailed systems, applied completely and unintelligently, do not
work well.
4. Some of the ideas, mixed with other ideas and selected to fit the
project and situation, turn out to be extremely useful, and become part
of the essential software project toolbox.
I've seen this pattern repeat several times, starting with "structured
programming" in the 1960's and 70's.
Given that background, I do not buy in to the idea of certification
tests on XP and SCRUM, or an "agile manifesto". I do think some of the
agile programming ideas are very useful in some situations.
As part of my dissertation research I wrote a program that needed to
change frequently in directions that were difficult to anticipate. I
would run some tests, look at the results, think of some new questions,
modify the program to answer the new questions, run some more tests etc.
I used a combination of test driven design, simplicity, and refactoring.
I did not even try to design for future change. Rather, when I had the
new questions and knew what I needed next week I would refactor anything
that made those changes unnecessarily difficult. I could not use pair
programming because it was an individual project. I was my own customer
so I definitely had continuous customer involvement.
I think my approach was much more effective, for that project, than
trying to anticipate what the requirements would be. I would have
guessed wrong in the early stages of writing and using the program, and
wasted time making the design support types of changes that were not needed.
I don't care whether it was "hacking" or not. It worked.
On the other hand, what worked well for a small program undergoing rapid
change and fully understood by the entire (one person) programming team
might not have been so good for a large program, with definite
objectives. For a sufficiently large program, programmers have detailed
knowledge of at most part of the program. Architectural rules, carefully
reviewed design changes, and long range planning become much more important.
> On 2/9/2012 9:45 AM, markspace wrote:
>> On 2/9/2012 3:53 AM, Lionel wrote:
>>> Agile == hacking.
>>> lol.
>> Actually, I feel the same way. But I also see a lot of folks (including
>> management and executives) who feel Agile is the best way to go. And
>> this is in Silicon Valley!
>> Anyone want to discuss pros and cons of various software development
>> methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid doing
>> it wrong.
>> Also, new thread, or jack this one?
> The subject line is fine for a discussion of agile project management,
> so I think hijack it.
> First of all, I have seen a general pattern to software development
> methodologies:
> 1. Some people come up with an approach to software development.
> 2. A lot of books get written, and complete, detailed systems combining
> many ideas are produced.
> 3. The detailed systems, applied completely and unintelligently, do not
> work well.
> 4. Some of the ideas, mixed with other ideas and selected to fit the
> project and situation, turn out to be extremely useful, and become part
> of the essential software project toolbox.
> I've seen this pattern repeat several times, starting with "structured
> programming" in the 1960's and 70's.
> Given that background, I do not buy in to the idea of certification
> tests on XP and SCRUM, or an "agile manifesto". I do think some of the
> agile programming ideas are very useful in some situations.
[ SNIP ]
> Patricia
Nicely put, I agree totally. And I'll add this: every new software
methodology posits a set of people that are somehow going to cooperate
much better with the new system than they ever did with any of the old
ones. When that fails to happen the complaint is inevitably "well, it's
not the methodology's fault if people don't apply it properly".
That's a truism. It's therefore very unhelpful. It's precisely why the
older methodologies didn't work so well either. Although each
methodology fails in its own ways.
You hit on the best approach: be aware of useful bits from all
methodologies. Learn your team (the entire team, including business)
quickly, and put pieces together. If anything actually is truly agile,
it's constructing and re-shaping the *methodology* as you go.
I believe that projects which succeed do so because of the team, and
that the team builds a custom methodology for the project. I also
believe that if the team isn't adequate there isn't a methodology on the
planet that can save the project.
AHS
-- ...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789
<iqraeducationalpor...@gmail.com> wrote:
> Agile software development is an iterative, incremental approach to
> developing and releasing software. A range of agile methodologies have
> emerged and they are based frequent releases, ongoing testing,
> customer and stakeholder participation throughout the development
> process, co-ownership of code and pair-programming.
> iQRA’s Agile Exam will test your knowledge about Agile Development
> including XP, and SCRUM techniques in the light of Agile Manifesto
On Thursday, February 9, 2012 2:09:01 PM UTC-8, Patricia Shanahan wrote:
> The subject line is fine for a discussion of agile project management,
> so I think hijack it.
Only by chance did I see these responses to a thread I had marked as spam.
Hijacking a spam thread is a terrible idea. Start a new one.
> On Feb 8, 11:51 pm, Iqra Educational Portal
> <iqraeducationalpor...@gmail.com> wrote:
>> Agile software development is an iterative, incremental approach to
>> developing and releasing software. A range of agile methodologies have
>> emerged and they are based frequent releases, ongoing testing,
>> customer and stakeholder participation throughout the development
>> process, co-ownership of code and pair-programming.
>> iQRA’s Agile Exam will test your knowledge about Agile Development
>> including XP, and SCRUM techniques in the light of Agile Manifesto
> All at the expense of quality but creates lots of "overhead" positions
> for largely worthless project managers of all kinds.
Agile method bashing is as stupid as mindlessly following the next development methodology fashion. There are situations where one approach works better than another and vice versa. By completely dismissing one you reduce your options and your opportunities to grow.
> On 10.02.2012 17:26, simplicity wrote:
>> On Feb 8, 11:51 pm, Iqra Educational Portal
>> <iqraeducationalpor...@gmail.com> wrote:
>>> Agile software development is an iterative, incremental approach to
>>> developing and releasing software. A range of agile methodologies have
>>> emerged and they are based frequent releases, ongoing testing,
>>> customer and stakeholder participation throughout the development
>>> process, co-ownership of code and pair-programming.
>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>> All at the expense of quality but creates lots of "overhead" positions
>> for largely worthless project managers of all kinds.
> Agile method bashing is as stupid as mindlessly following the next
> development methodology fashion. There are situations where one approach
> works better than another and vice versa. By completely dismissing one
> you reduce your options and your opportunities to grow.
Yes, I should add to my list of things that happen for each software
process cycle "Some people totally reject the new methodology." and, as
a result, miss out on adding ideas from the new methodology to their
software development toolkit.
On Thu, 9 Feb 2012, Patricia Shanahan wrote:
> On 2/9/2012 9:45 AM, markspace wrote:
>> Anyone want to discuss pros and cons of various software development >> methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid doing >> it wrong.
>> Also, new thread, or jack this one?
> The subject line is fine for a discussion of agile project management,
> so I think hijack it.
> First of all, I have seen a general pattern to software development
> methodologies:
> 1. Some people come up with an approach to software development.
> 2. A lot of books get written, and complete, detailed systems combining
> many ideas are produced.
> 3. The detailed systems, applied completely and unintelligently, do not
> work well.
> 4. Some of the ideas, mixed with other ideas and selected to fit the
> project and situation, turn out to be extremely useful, and become part
> of the essential software project toolbox.
> I've seen this pattern repeat several times, starting with "structured
> programming" in the 1960's and 70's.
In partial defence of agile, Extreme Programming, which i think of as being the true, pure, form of agile, was developed in a very practical way, by experimentation with the process used on the Chrysler Comprehensive Compensation System project. It's not a case of some egghead attaining enlightenment through contemplating their navel and then writing a fat book about it.
This is not to say that it doesn't suffer from the problem of being applied unintelligently.
XP also has a huge Achilles' heel, in that it demands a very different relationship with the customer to traditional processes. If you can't have that kind of relationship, then you can't actually do XP, and whatever halfway house you settle on is going to include some pretty weird compromises.
But, as you say, you can definitely pull some useful features from XP to use in your local process. Continuous integration and automatic testing have pretty much carried the day, i think. I contend that small releases, standups, Do The Simplest Thing That Could Possibly Work, spikes, and the idea that the customer's motivation should always be obvious are all valuable to any project.
Really, what XP is about is tightening feedback loops, which has the effect of shortening the period where you don't know something useful. Continuous integration, instead of integration once a week or whatever, shortens the period where you don't know if your code will merge with your colleagues'. Automatic testing, rather than waiting for QA to come along and test manually, shortens the period where you don't know if your code does what you expected. Small releases, rather than quarterly or more infrequent releases, shorten the period where you don't know if your users like what you've done. Daily standups, rather than weekly or monthly all-hands meetings, or newsletters, or the grapevine, shorten the period where you don't know what your colleagues are doing. DTSTTCPW, rather than big design up front, shortens the period where you don't know if the code you're writing will get anywhere. Spikes, rather than taking designs or assumptions on faith, shorten the period where you don't even know if your code could possibly get anywhere. The use of the customer motivation practices, like on-site customer (or at least business analyst/product manager sitting at the desk next to you) and using user stories, rather than working purely from technical specs, shorten the period where you don't know which technical decision best serves the customer's interest.
That's what XP is really about. People get hung up on the provocative, radical, possibly misguided, technical practices, like pair programming, or test-driven development, but those are actually not the important bits. What really matters is shortening the latency between a customer developing a desire for a feature, and their having it in their hands, because that is a cast-iron way of making sure that you are building the right thing.
tom
-- In case you don't know what CROWDSOURCING is, it's a stomach-churning
new media term obviously invented by a bastard made of piss. -- Charlie
Brooker
Patricia Shanahan wrote:
> Robert Klemme wrote:
> > simplicity wrote:
> >> Iqra Educational Portal
> >> <iqraeducationalpor...@gmail.com> wrote:
> >>> Agile software development is an iterative, incremental approach to
> >>> developing and releasing software. A range of agile methodologies have
> >>> emerged and they are based frequent releases, ongoing testing,
> >>> customer and stakeholder participation throughout the development
> >>> process, co-ownership of code and pair-programming.
> >>> iQRA’s Agile Exam will test your knowledge about Agile Development
> >>> including XP, and SCRUM techniques in the light of Agile Manifesto
> >> All at the expense of quality but creates lots of "overhead" positions
> >> for largely worthless project managers of all kinds.
"Largely worthless project managers", should such beings exist, are the problem, not whatever their buzzword /de jour/ might be.
> > Agile method bashing is as stupid as mindlessly following the next
> > development methodology fashion. There are situations where one approach
> > works better than another and vice versa. By completely dismissing one
> > you reduce your options and your opportunities to grow.
> Yes, I should add to my list of things that happen for each software
> process cycle "Some people totally reject the new methodology." and, as
> a result, miss out on adding ideas from the new methodology to their
> software development toolkit.
This is particularly dangerous for Agile, wherein I've heard, "If you're still doing 'Agile' the same way after three months, you're not doing Agile."
Agile's formalizes and enhances communication in the development process. (Software development is a process, not a "methodology".) Agile does not reinvent software development. I've seen it subverted by managers not conversant with how software development works. The main point of Agile is to deal with software development as it's really done, and make that manageable.
At its best, Agile improves communication about a project without additional impedance. It cannot rescue a team that disregards the realities of the development process.
If there's an idea to take away from Agile, it's to be unflinchingly open-eyed about reality. But then, that should be the ground of being for any development effort.
>>> Anyone want to discuss pros and cons of various software development
>>> methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid
>>> doing it wrong.
>>> Also, new thread, or jack this one?
>> The subject line is fine for a discussion of agile project management,
>> so I think hijack it.
>> First of all, I have seen a general pattern to software development
>> methodologies:
>> 1. Some people come up with an approach to software development.
>> 2. A lot of books get written, and complete, detailed systems combining
>> many ideas are produced.
>> 3. The detailed systems, applied completely and unintelligently, do not
>> work well.
>> 4. Some of the ideas, mixed with other ideas and selected to fit the
>> project and situation, turn out to be extremely useful, and become part
>> of the essential software project toolbox.
>> I've seen this pattern repeat several times, starting with "structured
>> programming" in the 1960's and 70's.
> In partial defence of agile, Extreme Programming, which i think of as
> being the true, pure, form of agile, was developed in a very practical
> way, by experimentation with the process used on the Chrysler
> Comprehensive Compensation System project. It's not a case of some
> egghead attaining enlightenment through contemplating their navel and
> then writing a fat book about it.
> This is not to say that it doesn't suffer from the problem of being
> applied unintelligently.
> XP also has a huge Achilles' heel, in that it demands a very different
> relationship with the customer to traditional processes. If you can't
> have that kind of relationship, then you can't actually do XP, and
> whatever halfway house you settle on is going to include some pretty
> weird compromises.
> But, as you say, you can definitely pull some useful features from XP to
> use in your local process. Continuous integration and automatic testing
> have pretty much carried the day, i think. I contend that small
> releases, standups, Do The Simplest Thing That Could Possibly Work,
> spikes, and the idea that the customer's motivation should always be
> obvious are all valuable to any project.
> Really, what XP is about is tightening feedback loops, which has the
> effect of shortening the period where you don't know something useful.
> Continuous integration, instead of integration once a week or whatever,
> shortens the period where you don't know if your code will merge with
> your colleagues'. Automatic testing, rather than waiting for QA to come
> along and test manually, shortens the period where you don't know if
> your code does what you expected. Small releases, rather than quarterly
> or more infrequent releases, shorten the period where you don't know if
> your users like what you've done. Daily standups, rather than weekly or
> monthly all-hands meetings, or newsletters, or the grapevine, shorten
> the period where you don't know what your colleagues are doing.
> DTSTTCPW, rather than big design up front, shortens the period where you
> don't know if the code you're writing will get anywhere. Spikes, rather
> than taking designs or assumptions on faith, shorten the period where
> you don't even know if your code could possibly get anywhere. The use of
> the customer motivation practices, like on-site customer (or at least
> business analyst/product manager sitting at the desk next to you) and
> using user stories, rather than working purely from technical specs,
> shorten the period where you don't know which technical decision best
> serves the customer's interest.
> That's what XP is really about. People get hung up on the provocative,
> radical, possibly misguided, technical practices, like pair programming,
> or test-driven development, but those are actually not the important
> bits. What really matters is shortening the latency between a customer
> developing a desire for a feature, and their having it in their hands,
> because that is a cast-iron way of making sure that you are building the
> right thing.
> tom
I agree with most of what you say, Tom, but I'll make the point that
while XP, as you state, is about tightening feedback loops, there has
likely always been a significant percentage of programmers and software
development teams who already knew that this is advantageous...well
before XP or Agile ever got tossed around as terms.
Did OO design patterns only come into existence when GOF published their
book? I think not: programmers had been using these techniques in some
shape or form since OOP got invented, except they didn't give 'em
well-known names.
I'll bet there were a whole bunch of coders, when Agile hit the streets
as a labeled methodology, who read up on it and thought to themselves,
Geez, I did s**t like that 20 or 30 years ago. You mentioned the need
for a special relationship with the customer for XP: guess what, that
special relationship exists in the absence of XP. In fact, _if_ that
special relationship obtains, *and* you have a software development team
that isn't inflexibly wedded to any particular methodology [1], many
core elements of Agile will naturally appear anyway.
I'm not against publicizing successful processes, but I don't think
there's any need for pretentious manifestos or packaged, named
"methodologies".
AHS
1. If your team lead and technical architect and PM all live and breathe
IEEE standards, well, settle in for the long haul. :-)
-- ...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789
> I'll bet there were a whole bunch of coders, when Agile hit the streets
> as a labeled methodology, who read up on it and thought to themselves,
> Geez, I did s**t like that 20 or 30 years ago. You mentioned the need
> for a special relationship with the customer for XP: guess what, that
> special relationship exists in the absence of XP. In fact, _if_ that
> special relationship obtains, *and* you have a software development team
> that isn't inflexibly wedded to any particular methodology [1], many
> core elements of Agile will naturally appear anyway.
I know I was doing test-driven development in 1983. I just didn't know
what to call it.
> "Largely worthless project managers", should such beings exist, are the > problem, not whatever their buzzword /de jour/ might be.
Well, often they are a symptom of an underlying problem in the
organization or corporate culture. In my experience, project managers
are rarely useless because they're incompetent, but more often because
they lack the necessary support or power in the organization to get
any traction.
Usually, project-based IT organizations are ... not.
Leif Roar Moldskred wrote:
> Lew wrote:
>> "Largely worthless project managers", should such beings exist, are the >> problem, not whatever their buzzword /de jour/ might be.
> Well, often they are a symptom of an underlying problem in the
> organization or corporate culture. In my experience, project managers
> are rarely useless because they're incompetent, but more often because
> they lack the necessary support or power in the organization to get
> any traction.
And often they are not such a symptom. Some people are just poseurs, and some of those people are managers. I've worked with such.
> Usually, project-based IT organizations are ... not.
> On Feb 8, 11:51 pm, Iqra Educational Portal
> <iqraeducationalpor...@gmail.com> wrote:
>> Agile software development is an iterative, incremental approach to
>> developing and releasing software. A range of agile methodologies have
>> emerged and they are based frequent releases, ongoing testing,
>> customer and stakeholder participation throughout the development
>> process, co-ownership of code and pair-programming.
>> iQRA’s Agile Exam will test your knowledge about Agile Development
>> including XP, and SCRUM techniques in the light of Agile Manifesto
> On 12-02-09 06:09 PM, Patricia Shanahan wrote:
>> First of all, I have seen a general pattern to software development
>> methodologies:
>> 1. Some people come up with an approach to software development.
>> 2. A lot of books get written, and complete, detailed systems combining
>> many ideas are produced.
>> 3. The detailed systems, applied completely and unintelligently, do not
>> work well.
>> 4. Some of the ideas, mixed with other ideas and selected to fit the
>> project and situation, turn out to be extremely useful, and become part
>> of the essential software project toolbox.
>> I've seen this pattern repeat several times, starting with "structured
>> programming" in the 1960's and 70's.
>> Given that background, I do not buy in to the idea of certification
>> tests on XP and SCRUM, or an "agile manifesto". I do think some of the
>> agile programming ideas are very useful in some situations.
> Nicely put, I agree totally. And I'll add this: every new software
> methodology posits a set of people that are somehow going to cooperate
> much better with the new system than they ever did with any of the old
> ones. When that fails to happen the complaint is inevitably "well, it's
> not the methodology's fault if people don't apply it properly".
> That's a truism. It's therefore very unhelpful. It's precisely why the
> older methodologies didn't work so well either. Although each
> methodology fails in its own ways.
> You hit on the best approach: be aware of useful bits from all
> methodologies. Learn your team (the entire team, including business)
> quickly, and put pieces together. If anything actually is truly agile,
> it's constructing and re-shaping the *methodology* as you go.
> I believe that projects which succeed do so because of the team, and
> that the team builds a custom methodology for the project. I also
> believe that if the team isn't adequate there isn't a methodology on the
> planet that can save the project.
Most new methodologies works fine as long as it is:
developer coming up with idea -> developers using idea
The problems arise when it becomes:
developer coming up with idea -> business guy wanting to make money -> PHB looking for a silver bullet -> developers using idea
On Sat, 11 Feb 2012 18:05:11 -0500, Arne Vajhøj wrote:
> Most agile processes does not specify overhead positions and quite a few
> does not even include project managers.
> I think you have completely misunderstood agile.
OTOH you may have misunderstood the ability of large and bureaucratic organisations to stuff up any project by putting it under the control of a semi-competent manager to buttresses his ignorance of the methodology and impresses his bosses by managing the crap out of it. I've seen this effect in action in government departments (HMCE as was circa 1990) and bastard offshoots of government (Cable & Wireless HQ in Hong Kong around the same time). The latter was incredible: internally it fit all the stereotypes of Whitewhall in the 1950s right down to the tea trolley, but I digress....
Question: How do modern Agile Development methodologies differ from their, presumably, ancestral Scrum and Sashimi approaches to development?
-- martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
> On Sat, 11 Feb 2012 18:05:11 -0500, Arne Vajhøj wrote:
>> Most agile processes does not specify overhead positions and quite a few
>> does not even include project managers.
>> I think you have completely misunderstood agile.
> OTOH you may have misunderstood the ability of large and bureaucratic
> organisations to stuff up any project by putting it under the control of
> a semi-competent manager to buttresses his ignorance of the methodology
> and impresses his bosses by managing the crap out of it. I've seen this
> effect in action in government departments (HMCE as was circa 1990) and
> bastard offshoots of government (Cable& Wireless HQ in Hong Kong around
> the same time). The latter was incredible: internally it fit all the
> stereotypes of Whitewhall in the 1950s right down to the tea trolley, but
> I digress....
But are you claiming that it is worse for agile than for non agile?
Or just ranting in general?
> Question: How do modern Agile Development methodologies differ from
> their, presumably, ancestral Scrum and Sashimi approaches to development?
>> "Largely worthless project managers", should such beings exist, are the >> problem, not whatever their buzzword /de jour/ might be.
>Well, often they are a symptom of an underlying problem in the
>organization or corporate culture. In my experience, project managers
>are rarely useless because they're incompetent, but more often because
>they lack the necessary support or power in the organization to get
>any traction.
>Usually, project-based IT organizations are ... not.
I worked on a project in the US for one of the regional telcos (Bell South) where the project managers had started as linemen for the phone company. They were great SMEs but didn't know squat about project management.
> > On Feb 8, 11:51 pm, Iqra Educational Portal
> > <iqraeducationalpor...@gmail.com> wrote:
> >> Agile software development is an iterative, incremental approach to
> >> developing and releasing software. A range of agile methodologies have
> >> emerged and they are based frequent releases, ongoing testing,
> >> customer and stakeholder participation throughout the development
> >> process, co-ownership of code and pair-programming.
> >> iQRA’s Agile Exam will test your knowledge about Agile Development
> >> including XP, and SCRUM techniques in the light of Agile Manifesto
> > All at the expense of quality but creates lots of "overhead" positions
> > for largely worthless project managers of all kinds.
> Most agile processes does not specify overhead positions
> and quite a few does not even include project managers.
> I think you have completely misunderstood agile.
> Arne
Misunderstood? I am judging from my personal experience. I was part of
agile development in 3 environments: small organization (< 40 people)
which was trying to implement it, mid-size and large - by large I mean
> 800 employees. Each was a failure in one aspect or another. And in
each, the common themes were (1) a blotted overhead, (2) questionable
quality, (3) lack of architectural consistency and (4) reoccuring
breaks of the old and often obscure features.
Interesting that when I raised these issues (with examples) during one
of the internal seminars on agile, the presented, some "big kahoona"
consultant on agile, quickly diverted into a different topic
> If there's an idea to take away from Agile, it's to be unflinchingly open-eyed
> about reality. But then, that should be the ground of being for any development
> effort.
Or maybe life in total? Ignorance of reality usually negatively fires back - although it sometimes works remarkably good for surprising long periods of time...
> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk> wrote:
>> On 2/10/2012 11:26 AM, simplicity wrote:
>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>> <iqraeducationalpor...@gmail.com> wrote:
>>>> Agile software development is an iterative, incremental approach to
>>>> developing and releasing software. A range of agile methodologies have
>>>> emerged and they are based frequent releases, ongoing testing,
>>>> customer and stakeholder participation throughout the development
>>>> process, co-ownership of code and pair-programming.
>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>> All at the expense of quality but creates lots of "overhead" positions
>>> for largely worthless project managers of all kinds.
>> Most agile processes does not specify overhead positions
>> and quite a few does not even include project managers.
>> I think you have completely misunderstood agile.
> Misunderstood? I am judging from my personal experience. I was part of
> agile development in 3 environments: small organization (< 40 people)
> which was trying to implement it, mid-size and large - by large I mean
>> 800 employees. Each was a failure in one aspect or another. And in
> each, the common themes were (1) a blotted overhead, (2) questionable
> quality, (3) lack of architectural consistency and (4) reoccuring
> breaks of the old and often obscure features.
> Interesting that when I raised these issues (with examples) during one
> of the internal seminars on agile, the presented, some "big kahoona"
> consultant on agile, quickly diverted into a different topic
The fact that 3 agile projects had large overhead is not
really an indication that large overhead is a given result
of agile.
Arne Vajhøj wrote:
> On 2/12/2012 1:43 AM, simplicity wrote:
>> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk> wrote:
>>> On 2/10/2012 11:26 AM, simplicity wrote:
>>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>>> <iqraeducationalpor...@gmail.com> wrote:
>>>>> Agile software development is an iterative, incremental approach to
>>>>> developing and releasing software. A range of agile methodologies have
>>>>> emerged and they are based frequent releases, ongoing testing,
>>>>> customer and stakeholder participation throughout the development
>>>>> process, co-ownership of code and pair-programming.
>>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>>> All at the expense of quality but creates lots of "overhead" positions
>>>> for largely worthless project managers of all kinds.
>>> Most agile processes does not specify overhead positions
>>> and quite a few does not even include project managers.
>>> I think you have completely misunderstood agile.
>> Misunderstood? I am judging from my personal experience. I was part of
>> agile development in 3 environments: small organization (< 40 people)
>> which was trying to implement it, mid-size and large - by large I mean
>>> 800 employees. Each was a failure in one aspect or another. And in
>> each, the common themes were (1) a blotted overhead, (2) questionable
>> quality, (3) lack of architectural consistency and (4) reoccuring
>> breaks of the old and often obscure features.
>> Interesting that when I raised these issues (with examples) during one
>> of the internal seminars on agile, the presented, some "big kahoona"
>> consultant on agile, quickly diverted into a different topic
> The fact that 3 agile projects had large overhead is not
> really an indication that large overhead is a given result
> of agile.
I've also seen non-Agile projects with large overhead.
That said, for an 800 person project I would want strong architectural
control to ensure clean interfaces. It is very easy for a program that
big to get out of control and become unmaintainable.
