Agile Project Management

[Iqra Educational Portal]

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=

[Lionel]

Agile == hacking.

lol.

[markspace]

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?

[Lew]

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

[Patricia Shanahan]

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

[Arved Sandstrom]

[ 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

[simplicity]

On Feb 8, 11:51 pm, Iqra Educational Portal

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.

[Lew]

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

[Robert Klemme]

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/

[Patricia Shanahan]

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

[Tom Anderson]

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

[Lew]

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

[Arved Sandstrom]

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

[Patricia Shanahan]

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

[Leif Roar Moldskred]

Lew <lewb...@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

[Lew]

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

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[Martin Gregorie]

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 |

[Arne Vajhøj]

On 2/11/2012 6:46 PM, Martin Gregorie wrote:
> 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?

I think Scrum is still modern.

:-)

Arne

[EricF]

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

[simplicity]

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

[Robert Klemme]

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

[Arne Vajhøj]

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

[Patricia Shanahan]

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.

Patricia

[Arved Sandstrom]

Brings a project to mind that I was loosely associated with. The client
(it was an internal infrastructure project) was advised to use Scrum.
Best of intentions all round. People with adequate understanding of
their duties in Scrum were assigned to the main roles, and the process
was faithfully followed.

Main problem was that half the developers couldn't have coded their way
out of a piss-soaked paper bag. A lot of them were scraped up at the
last moment on contract to fill resource requirements. Mediocre would
have been too kind a word for their programming abilities.

The project failed. Actually it "succeeded", but that was a political
label. Anyway, the project could not have succeeded with the assigned
developers using any methodology known to man. So not Agile's fault, not
reasonably so.

I saw another mid-sized agile project encounter serious difficulties
because UI requirements were not being adequately communicated. Verbal
and text records and artifacts were not accurately capturing what the
business wanted. In hindsight the team should have used visuals:
probably high-fidelity wireframes.

But this lack of proper communication would have caused similar (maybe
worse) difficulties under any other methodology. So not Agile's fault,
not really.

What all of this (there have been more agile projects :-)) tells me is
that Agile succeeds when you've got the right people (in software
development this means above-average in key roles, and at least
competent in all other roles) with the right motives, buy-in by all
stakeholders to follow process, and the right tools. Agile fails (or has
serious problems) when you're missing any of that.

Oddly enough, *other* methodologies also succeed or fail according as
the same positive factors are present or absent. This leads me to
believe that the methodology is considerably less important than having
the right people, making sure they are informed as to procedures, having
a doable problem, and ensuring that all process tools are good ones.

For me the major truth, as I admit is being *publicized* well by Agile
proponents, is frequent feedback/communication. Frequent working
software delivery is simply part of that. When expressed that way, who
actually believes that the Agile folks were the first to invent these
concepts?

A side-note about (changing) requirements: when people who purport to
follow Agile tell me that requirements change all the time, and *that*
is why agile is necessary, I tune them out. When an agile enthusiast
puts it differently, and tells me that the process allows for
requirements to be gathered as needed, and acted upon as needed (almost
JIT requirements), then I am prepared to listen.

The reason I say this is, in my entire career I have encountered few
projects where the requirements really changed through the course of the
work. What does happen often is that initial requirements gathering is
poor, feedback mechanisms suck, and it's only late in the project when
the correct requirement is agreed. 9 times out of 10 though, at project
end you can look back and say, yes, all of these requirements were known
at the start. In *theory*.

I wish that Agile folks didn't refer to "changing" requirements so much.
That's usually an incorrect characterization. If they rather stated that
Agile has an adaptive process for dealing with flawed requirements
gathering, I'd buy that.

AHS

[Martin Gregorie]

On Sat, 11 Feb 2012 18:58:20 -0500, Arne Vajhøj wrote:

> On 2/11/2012 6:46 PM, Martin Gregorie wrote:
>> 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?
>

Nope - just pointing out that some managers can sscrew up anything and/or
be officious pricks. Here's an HMCE example. We were using PRINCE, a
somewhat prescriptive project management scheme much loved by people in
UK government. One of its requirements is that every document type has to
have a template, which describes the document's content, when to use it
and why. PRINCE doesn't provide the templates because they're project
specific. I don't have a problem with this for a widely used document
such as a requirement or module description, but the managers were pretty
much jobsworths and didn't really know what they were doing. Because of
the 'every document must match its template' requirement, I ended up
having to produce a template for a document which would only ever be used
once in the project. I managed to restrain myself from demanding that
they supply a template for defining templates, but that took real
willpower.

>> Question: How do modern Agile Development methodologies differ from
>> their, presumably, ancestral Scrum and Sashimi approaches to
>> development?
>
> I think Scrum is still modern.
>

Yes, I regularly see it specified in job adverts. As it seems to have
first appeared as a recognised methodology in the mid '80s, I was
wondering if it had mutated and if I'm right in assuming that Agile is
son-of-Scrum.

It appears that successful projects I worked on through the late 80s and
90s were more or less all organised along Scrum lines, though with an
added prefix that the core project team was generally assembled to run
the bid process, usually along Scrum lines, and went on to do the project
if we won it.

[Arne Vajhøj]

That type of stuff happens all the time.

>>> Question: How do modern Agile Development methodologies differ from
>>> their, presumably, ancestral Scrum and Sashimi approaches to
>>> development?
>>
>> I think Scrum is still modern.
>>
> Yes, I regularly see it specified in job adverts. As it seems to have
> first appeared as a recognised methodology in the mid '80s, I was
> wondering if it had mutated and if I'm right in assuming that Agile is
> son-of-Scrum.

I thought the name Scrum was first invented in 1991.

But as someone stated elsewhere in this thread then most
methodologies does not contain many new ideas, but more
put a label on ideas already used (and to some extent bundle
certain ideas together).

Arne

[Arne Vajhøj]

No methodology is so good that it can make incompetent programmers
succeed.

But I think that bad or lack of methodology can make competent
programmers fail.

> A side-note about (changing) requirements: when people who purport to
> follow Agile tell me that requirements change all the time, and *that*
> is why agile is necessary, I tune them out. When an agile enthusiast
> puts it differently, and tells me that the process allows for
> requirements to be gathered as needed, and acted upon as needed (almost
> JIT requirements), then I am prepared to listen.
>
> The reason I say this is, in my entire career I have encountered few
> projects where the requirements really changed through the course of the
> work. What does happen often is that initial requirements gathering is
> poor, feedback mechanisms suck, and it's only late in the project when
> the correct requirement is agreed. 9 times out of 10 though, at project
> end you can look back and say, yes, all of these requirements were known
> at the start. In *theory*.
>
> I wish that Agile folks didn't refer to "changing" requirements so much.
> That's usually an incorrect characterization. If they rather stated that
> Agile has an adaptive process for dealing with flawed requirements
> gathering, I'd buy that.

It happens that requirements really change. But for the development
process changing requirements doc due to better understanding the
real requirements and changing requirements due to real changing
requirements has the same impact.

Arne

[Arne Vajhøj]

Yep.

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

I was focusing on the overhead and project manager aspect
in simplicity's post.

Architecture is another story.

Some agile developers think that architecture has no place
in agile.

You disagree.

I disagree.

Fowler disagrees!

http://martinfowler.com/articles/designDead.html#GrowingAnArchitecture

For anything but a very small project an architecture is needed.

It is a prerequisite to start agile development.

Some parts of the architecture may change along the way. But that
is more a fact of life than an agile idea.

What may confuse some people to believe that they succeeded
without an architecture is when the architecture was given
and not done as part of the project because the basic
system was already in place.

Arne

[Arved Sandstrom]

I don't think the OP meant ~800 person *project*.

Once we start getting into these examples I'd like to see a clear
understanding of what numbers are involved in what roles on what pieces.
I can think of examples from my own experience where a software
development team of maybe a dozen or fifteen folks (developers, team
lead, technical architect, PM, QA/QC types etc) fell into the following
slots:

1. as the only software development team in a small (<30 people) product
company;

2. as one of several similar sized teams in a ~100 person IT shop in a
small/mid-sized (several thousand people) services organization. Each
team working independently on their own IT projects;

3. As the only team working on a specific product in a large (10,000+
persons) IT company. Dozens upon dozens of other teams, many larger,
some smaller. But this team is insular and works on one thing.

In these 3 examples mentioning the size of the organization (~25, ~2000,
~25000) is irrelevant.

You're absolutely right, though, Patricia: for an 800-person *project*
you sure would want clean interfaces. Myself I don't think that adopting
agile is either going to help you or hinder you in achieving that good
architecture; either you know what you're doing or you don't.

[Lew]

Arved Sandstrom wrote:
> I don't think the OP meant ~800 person *project*.
>
> Once we start getting into these examples I'd like to see a clear
> understanding of what numbers are involved in what roles on what pieces.
> I can think of examples from my own experience where a software
> development team of maybe a dozen or fifteen folks (developers, team
> lead, technical architect, PM, QA/QC types etc) fell into the following
> slots:
>
> 1. as the only software development team in a small (<30 people) product
> company;
>
> 2. as one of several similar sized teams in a ~100 person IT shop in a
> small/mid-sized (several thousand people) services organization. Each
> team working independently on their own IT projects;
>
> 3. As the only team working on a specific product in a large (10,000+
> persons) IT company. Dozens upon dozens of other teams, many larger,
> some smaller. But this team is insular and works on one thing.
>
> In these 3 examples mentioning the size of the organization (~25, ~2000,
> ~25000) is irrelevant.
>
> You're absolutely right, though, Patricia: for an 800-person *project*
> you sure would want clean interfaces. Myself I don't think that adopting
> agile is either going to help you or hinder you in achieving that good
> architecture; either you know what you're doing or you don't.

If you have structured an 800-person project in this sense, not decomposed
into 5- to 12-person autonomous projects, then either you don't know what

you're doing or you don't.

--
Lew

[Arne Vajhøj]

If would put it the exact opposite if a 800 person project is split
into 80 autonomous projects of 10 persons, then the management it
totally clueless.

Arne

[Arved Sandstrom]

On 12-02-12 12:03 PM, Arne Vajhøj wrote:
> On 2/12/2012 10:43 AM, Arved Sandstrom wrote:

[ SNIP ]

>> A side-note about (changing) requirements: when people who purport to
>> follow Agile tell me that requirements change all the time, and *that*
>> is why agile is necessary, I tune them out. When an agile enthusiast
>> puts it differently, and tells me that the process allows for
>> requirements to be gathered as needed, and acted upon as needed (almost
>> JIT requirements), then I am prepared to listen.
>>
>> The reason I say this is, in my entire career I have encountered few
>> projects where the requirements really changed through the course of the
>> work. What does happen often is that initial requirements gathering is
>> poor, feedback mechanisms suck, and it's only late in the project when
>> the correct requirement is agreed. 9 times out of 10 though, at project
>> end you can look back and say, yes, all of these requirements were known
>> at the start. In *theory*.
>>
>> I wish that Agile folks didn't refer to "changing" requirements so much.
>> That's usually an incorrect characterization. If they rather stated that
>> Agile has an adaptive process for dealing with flawed requirements
>> gathering, I'd buy that.
>
> It happens that requirements really change. But for the development
> process changing requirements doc due to better understanding the
> real requirements and changing requirements due to real changing
> requirements has the same impact.
>
> Arne
>

You're absolutely correct. I acknowledge that the impact is the same.
And given that I've never seen a project using any methodology that did
a great job of classic requirements analysis at the beginning, *and* I
don't think that that can ever be fixed, I'm totally cool with a system
that adapts to this reality.

I do however wish that folks would make the distinction. Calling
something a changing requirement when it's not is a copout. Usually an
organization does benefit from a quality effort at semi-classical
initial stage requirements analysis; you don't want to hide the fact as
part of your process that you had such-and-such failures in that first
stage, by calling everything a "changed" requirement.

I have often seen where a "product owner" (in the agile sense, but not
necessarily in an agile environment) makes an early decision, and the
team builds on that decision. Later on the individual changes his mind
and makes a new decision. This frequently happens when he or she sees
the first screenshots or working product and doesn't like it, or some
individual who wasn't in on the initial decision-making gets informed
about Feature X and raises a red flag about unsuitability of approach,
or similar.

The team then makes changes based on the new decision.

To me that's not a changing requirement. What it is, is flawed and
imperfect requirements gathering. It's not the fault of the product
owner either: it's the fault of the requirements analysts and their
developer assistants to present the product owner with sufficient data
and context to make an informed and stable decision.

Having said all that, I've seen this happen so many hundreds of times
that I don't think it can be fixed. Like I said above I am totally cool
with a system that adapts better to real-world requirements gathering.
As you said, it doesn't matter *at the 11th hour* whether that 11th hour
change is caused by imperfect analysis, or by a genuine change.

[Leif Roar Moldskred]

Arved Sandstrom <asandstr...@eastlink.ca> wrote:
>
> Oddly enough, *other* methodologies also succeed or fail according as
> the same positive factors are present or absent. This leads me to
> believe that the methodology is considerably less important than having
> the right people, making sure they are informed as to procedures, having
> a doable problem, and ensuring that all process tools are good ones.

Yes, this is what I personally dislike about the Agile methodologies /
movement. While there are certain useful techniques and tools found
under the Agile label, the actual _project management_ bit seems to
boil down to "presume a near-ideal project with little need for
management, then paint it Agile."

> For me the major truth, as I admit is being *publicized* well by Agile
> proponents, is frequent feedback/communication.

I don't know. I think there is a danger in Agile making the feedback
loops too tight so that the overall progress of the project is
forgotten in the focus on day to day (or week to week) progress. While
it's true that a journey of a thousand miles start with a single step,
it doesn't follow that the best way to measure the progress of the
journey is by counting your steps.

I wholeheartedly agree with your view on changing versus hidden
requirements.

--
Leif Roar Moldskred

[Arne Vajhøj]

Imagine some autonomous web UI projects choosing:
- PHP
- Struts
- JSF
and some autonomous persistence projects choosing:
- Oracle with SP's
- DB2 with Hibernate

Arne

[Arne Vajhøj]

On 2/12/2012 12:25 PM, Arved Sandstrom wrote:
> On 12-02-12 12:03 PM, Arne Vajhøj wrote:
>> On 2/12/2012 10:43 AM, Arved Sandstrom wrote:
>>> A side-note about (changing) requirements: when people who purport to
>>> follow Agile tell me that requirements change all the time, and *that*
>>> is why agile is necessary, I tune them out. When an agile enthusiast
>>> puts it differently, and tells me that the process allows for
>>> requirements to be gathered as needed, and acted upon as needed (almost
>>> JIT requirements), then I am prepared to listen.
>>>
>>> The reason I say this is, in my entire career I have encountered few
>>> projects where the requirements really changed through the course of the
>>> work. What does happen often is that initial requirements gathering is
>>> poor, feedback mechanisms suck, and it's only late in the project when
>>> the correct requirement is agreed. 9 times out of 10 though, at project
>>> end you can look back and say, yes, all of these requirements were known
>>> at the start. In *theory*.
>>>
>>> I wish that Agile folks didn't refer to "changing" requirements so much.
>>> That's usually an incorrect characterization. If they rather stated that
>>> Agile has an adaptive process for dealing with flawed requirements
>>> gathering, I'd buy that.
>>
>> It happens that requirements really change. But for the development
>> process changing requirements doc due to better understanding the
>> real requirements and changing requirements due to real changing
>> requirements has the same impact.

I am very skeptical about whether we will ever be able to produce
perfect requirements.

The people providing input for requirements are just that - humans.
And most of them are not experts in system requirements.

So mistakes happen. All the time.

It is like bugs in code - no matter how good developers
you hire, then the first version of the code will contain
bugs. So we have code reviews, test etc. to try and find them.

Arne

[Lew]

Arne Vajhøj wrote:

Full communication between each member of a team requires geometric
increase in communication bandwidth with team size. Autonomy, within a
shared framework as you aptly point out, is a necessity for such a large
organization to function effectively.

In practice it works out all right that one team chooses PHP and another
JSF, or as in my experience, one programmer C and another Fortran. What's
the harm? Where teams must share a common resource, say that choice
between Oracle and DB2 you describe, one of those small teams could be the
database team. It would then function autonomously to serve the needs of
the other teams, the database team's clients.

Surely you don't profess that 800 people on a team should work as a single
unit? That is a proven antipattern. You have to break that large a group
into manageable sizes, and those smaller groups must have autonomy.
However, not to the /reductio ad absurdum/ point you mention. Analogously,
you and I have autonomy in our posts to this newsgroup, yet we work within
a common framework of the English language. Autonomy is not synonymous
with isolation.

--
Lew

[Arne Vajhøj]

Work will need to be split up.

No argument about that.

I think that has generally been agreed on for 5000+ years.

But autonomous is another story.

Technical leadership is required to ensure that:
- the parts work together
- the parts combined provides the whole
- the parts does not overlap
- it ends up being maintainable
- it ends up being cost efficient

Arne

[Arne Vajhøj]

On 2/12/2012 3:55 PM, Lew wrote:

Maybe technical leadership ~= shared framework??

> In practice it works out all right that one team chooses PHP and another
> JSF,

Single signon and session sharing becomes a problem.

> or as in my experience, one programmer C and another Fortran.

Increases skill sets necessary for maintenance.

> Where teams must share a common resource, say that choice
> between Oracle and DB2 you describe, one of those small teams could be the
> database team. It would then function autonomously to serve the needs of
> the other teams, the database team's clients.

If they pick Oracle and operations know DB2 and not Oracle, then
that will not work.

> Surely you don't profess that 800 people on a team should work as a single
> unit? That is a proven antipattern. You have to break that large a group
> into manageable sizes, and those smaller groups must have autonomy.

I disagree on that.

> However, not to the /reductio ad absurdum/ point you mention. Analogously,
> you and I have autonomy in our posts to this newsgroup, yet we work within
> a common framework of the English language. Autonomy is not synonymous
> with isolation.

Speaking English is sufficient to understand what the other
part is saying.

But making a big IT project succeed require a lot more than that.

Arne

[Lew]

Again, there's a difference between autonomy and isolation. Within the
overarching framework, each team must be autonomous with respect to its
own responsibilities. You seem to interpret "autonomy" as "no one
communicates with each other". That's not what it means. What it does
mean is, "Each group makes its own decisions within its sphere of
responsibility."

Your counter-examples do not negate autonomy, they negate isolation.

--
Lew

[EricF]

In article <92d0e832-6c70-4dc6...@vv9g2000pbc.googlegroups.com>, simplicity <stella...@live.ca> wrote:

>On Feb 11, 4:05=A0pm, Arne Vajh=F8j <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> =A0wrote:

>> >> 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=92s 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=3D11&type=3D

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

I've worked at 5 or 6 places that say they did agile development. They touched
on aspects of it, but aside from 1 exception, I would say they really were not
very agile and their processes were a bit of a mess.

Eric

[Gene Wirchenko]

On Fri, 10 Feb 2012 16:22:36 -0800 (PST), Lew <lewb...@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

[simplicity]

On Feb 12, 9:38 pm, e...@invalid.com (EricF) wrote:

> In article <92d0e832-6c70-4dc6-9c9f-71f588920...@vv9g2000pbc.googlegroups.com>, simplicity <stella_pig...@live.ca> wrote:
> >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
>
> I've worked at 5 or 6 places that say they did agile development. They touched
> on aspects of it, but aside from 1 exception, I would say they really were not
> very agile and their processes were a bit of a mess.
>
> Eric

This is very much my observation as well. The most comical was the
experience in small company. I think the only agile principle
management understood was that "developers working on the project
should seat together". As it was a consulting company with project
span averaging 6-8 months, you can imagine: people being constantly
moved around. My proverbial "straw that broke camel's back" was when
I inherited the desk with no less than 70 empty Coke cans and the
traces of lunches from last 6 months. :-):-)

However, this particular case notwithstanding, my failure rate is 3 of
3, yours 5 of 6. With stats like this it is hard to defend something.

[Patricia Shanahan]

Has anyone had a successful project that attempted to apply *any*
process that sort of management approach?

My position is that intelligent choice of project-appropriate techniques
works, and works better with a large toolbox from which to pick
techniques, but unintelligent imposition of an arbitrary choice of
techniques does not work.

Sitting together can be useful, especially when a task requires several
different types of knowledge, so that a team has to work together almost
continuously, rather than dividing up the work and each doing their own
piece. It does have costs, and those must be compared to the benefits
for a particular project and situation, but isn't that the case for
anything?

Patricia

[Leif Roar Moldskred]

Patricia Shanahan <pa...@acm.org> wrote:

> Sitting together can be useful, especially when a task requires several
> different types of knowledge, so that a team has to work together almost
> continuously, rather than dividing up the work and each doing their own
> piece.

I think the real benefit of co-location is not that the members are
more accessible to the rest of the team, but that they're less
accessible to other people.

In my experience, the two factors that are most likely to scupper a
development project is a) insufficient and shoddy ground work and b)
developers not being able to focus on the project because of other
demands (formal or informal) on their time.

--
Leif Roar Moldskred

[Patricia Shanahan]

I think it depends. In one case I was in a small team that was put
together for the purpose a fixing an urgent problem. Fixing the problem
was the highest priority the organization had, and our managers were
protecting us from other demands. We needed to work together to share
knowledge. In other cases, I can see that it would help the team members
focus.

Patricia

[Arne Vajhøj]

On 2/14/2012 11:04 AM, simplicity wrote:
> On Feb 12, 9:38 pm, e...@invalid.com (EricF) wrote:
>> In article<92d0e832-6c70-4dc6-9c9f-71f588920...@vv9g2000pbc.googlegroups.com>, simplicity<stella_pig...@live.ca> wrote:
>>> 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
>>
>> I've worked at 5 or 6 places that say they did agile development. They touched
>> on aspects of it, but aside from 1 exception, I would say they really were not
>> very agile and their processes were a bit of a mess.
>

> This is very much my observation as well. The most comical was the
> experience in small company. I think the only agile principle
> management understood was that "developers working on the project
> should seat together". As it was a consulting company with project
> span averaging 6-8 months, you can imagine: people being constantly
> moved around. My proverbial "straw that broke camel's back" was when
> I inherited the desk with no less than 70 empty Coke cans and the
> traces of lunches from last 6 months. :-):-)
>
> However, this particular case notwithstanding, my failure rate is 3 of
> 3, yours 5 of 6. With stats like this it is hard to defend something.

If you can make "4 or 5 out of 5 or 6 called agile that were not agile"
to "5 of 6 agile failing", then it is pretty easy to discard things.

But ...

Arne

[Arne Vajhøj]

On 2/12/2012 8:04 PM, Lew wrote:
> Arne Vajhřj wrote:
>> Lew wrote:
>>> Arne Vajhřj wrote:

Really?

I consider isolation to be a question about information flow and
autonomy to be a matter of having decision power.

And I am definitely talking about having decision power.

Arne

[Lew]

Arne Vajhøj wrote:
> I consider isolation to be a question about information flow and
> autonomy to be a matter of having decision power.
>
> And I am definitely talking about having decision power.

Sigh. So am I. I am saying that smaller groups need independent
decision power. That is what I am saying.

But they don't make these decisions in a vacuum or without consideration
for the larger enterprise. That's not what I'm advocating. The notion
of autonomy does not imply complete and utter independence of action
without any regard for the larger community. That is your
misrepresentation. Unless you do actually espouse that every person in
and 800-person "team" must communicate about every decision with every
one of the other 799?

There is a middle ground between anarchy and despotism. There are
degrees of autonomy. Of course, as you say, decisions are made
cooperatively between groups, but your counterexamples to the notion
of autonomy were ludicrous. Straw men. They did not speak to autonomy.
They spoke to isolation.

--
Lew