Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11874 > unrolled thread

Agile Project Management

Back to article view | Back to comp.lang.java.programmer

Contents

  Agile Project Management Iqra Educational Portal <iqraeducationalportal@gmail.com> - 2012-02-08 22:51 -0800
    Re: Agile Project Management Lionel <lionelv@none.com> - 2012-02-09 21:53 +1000
      Re: Agile Project Management markspace <-@.> - 2012-02-09 09:45 -0800
        Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-09 14:09 -0800
          Re: Agile Project Management Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-09 20:24 -0400
            Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 18:09 -0500
          Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-10 09:03 -0800
          Re: Agile Project Management Tom Anderson <twic@urchin.earth.li> - 2012-02-11 00:25 +0000
            Re: Agile Project Management Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-10 22:32 -0400
              Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-10 18:35 -0800
    Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-09 09:45 -0800
    Re: Agile Project Management simplicity <stella_pigeon@live.ca> - 2012-02-10 08:26 -0800
      Re: Agile Project Management Robert Klemme <shortcutter@googlemail.com> - 2012-02-10 23:28 +0100
        Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-10 15:40 -0800
          Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-10 16:22 -0800
            Re: Agile Project Management Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-11 01:04 -0600
              Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-11 12:23 -0800
              Re: Agile Project Management eric@invalid.com (EricF) - 2012-02-12 05:17 +0000
            Re: Agile Project Management Robert Klemme <shortcutter@googlemail.com> - 2012-02-12 14:52 +0100
            Re: Agile Project Management Gene Wirchenko <genew@ocis.net> - 2012-02-13 11:33 -0800
      Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 18:05 -0500
        Re: Agile Project Management Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-11 23:46 +0000
          Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 18:58 -0500
            Re: Agile Project Management Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-12 15:46 +0000
              Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 10:58 -0500
        Re: Agile Project Management simplicity <stella_pigeon@live.ca> - 2012-02-11 22:43 -0800
          Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 09:19 -0500
            Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-12 07:08 -0800
              Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 11:11 -0500
              Re: Agile Project Management Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-12 12:12 -0400
                Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-12 09:00 -0800
                  Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 12:06 -0500
                    Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 13:13 -0500
                      Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-12 12:55 -0800
                        Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 16:29 -0500
                        Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 16:35 -0500
                          Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-12 17:04 -0800
                            Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-16 21:28 -0500
                              Re: Agile Project Management Lew <lewbloch@gmail.com> - 2012-02-17 02:15 -0800
            Re: Agile Project Management Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-12 11:43 -0400
              Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 11:03 -0500
                Re: Agile Project Management Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-12 13:25 -0400
                  Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 13:34 -0500
              Re: Agile Project Management Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-12 11:55 -0600
          Re: Agile Project Management eric@invalid.com (EricF) - 2012-02-13 04:38 +0000
            Re: Agile Project Management simplicity <stella_pigeon@live.ca> - 2012-02-14 08:04 -0800
              Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-14 08:50 -0800
                Re: Agile Project Management Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-14 11:11 -0600
                  Re: Agile Project Management Patricia Shanahan <pats@acm.org> - 2012-02-14 09:17 -0800
              Re: Agile Project Management Arne Vajhøj <arne@vajhoej.dk> - 2012-02-16 21:26 -0500

Page 1 of 3  [1] 2 3  Next page →

#11874 — Agile Project Management

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

http://iqra.org.pk/certification-startup.aspx?CertID=11&type=

[toc] | [next] | [standalone]

#11876

Agile == hacking.

lol.


On 09/02/12 16:51, Iqra Educational Portal 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
>
> http://iqra.org.pk/certification-startup.aspx?CertID=11&type=

[toc] | [prev] | [next] | [standalone]

#11879

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?

[toc] | [prev] | [next] | [standalone]

#11884

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.

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.

Patricia

[toc] | [prev] | [next] | [standalone]

#11895

On 12-02-09 06:09 PM, Patricia Shanahan wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#11954

On 2/9/2012 7:24 PM, Arved Sandstrom wrote:
> 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

Arne

[toc] | [prev] | [next] | [standalone]

#11909

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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11926

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

[toc] | [prev] | [next] | [standalone]

#11929

On 12-02-10 08:25 PM, Tom Anderson wrote:
> 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
> 
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

[toc] | [prev] | [next] | [standalone]

#11930

Arved Sandstrom wrote:
...
> 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.

Patricia

[toc] | [prev] | [next] | [standalone]

#11880

Iqra Educational Portal Spammer wrote:
> 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.

Spammer.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11904

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
>
> http://iqra.org.pk/certification-startup.aspx?CertID=11&type=

Agile is garbage. Code before thinking.

All at the expense of quality but creates lots of "overhead" positions
for largely worthless project managers of all kinds.

[toc] | [prev] | [next] | [standalone]

#11921

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
>>
>> http://iqra.org.pk/certification-startup.aspx?CertID=11&type=
>
> Agile is garbage. Code before thinking.
>
> 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.

Regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#11924

On 2/10/2012 2:28 PM, Robert Klemme wrote:
> 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
>>>
>>> http://iqra.org.pk/certification-startup.aspx?CertID=11&type=
>>
>> Agile is garbage. Code before thinking.
>>
>> 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.

Patricia

[toc] | [prev] | [next] | [standalone]

#11927

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
> >>>
> >>> httq://iqra.orc.puke/certification-startup.aspx?CertID=11&type=
> >>
> >> Agile is garbage. Code before thinking.
> >>
> >> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11931

Lew <lewbloch@gmail.com> 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. 

Usually, project-based IT organizations are ... not.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#11947

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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11962

In article <4LOdnXC9bK6cjqvSnZ2dnUVZ8qidnZ2d@giganews.com>, Leif Roar Moldskred <leifm@dimnakorr.com> wrote:
>Lew <lewbloch@gmail.com> 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. 
>
>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.

Eric

[toc] | [prev] | [next] | [standalone]

#11972

On 11.02.2012 01:22, Lew wrote:

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

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#12010

On Fri, 10 Feb 2012 16:22:36 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>Patricia Shanahan wrote:

[snip]

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

     So call it "Churn".

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web