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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11953

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.

Arne

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

#11955

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       |

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

#11956

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

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

#11982

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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#11983

On 2/12/2012 10:46 AM, Martin Gregorie wrote:
> 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.

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

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

#11967

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

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

#11973

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

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

#11980

Arne Vajhøj wrote:
> On 2/12/2012 1:43 AM, simplicity wrote:
>> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk>  wrote:
>>> On 2/10/2012 11:26 AM, simplicity wrote:
>>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>>> <iqraeducationalpor...@gmail.com>    wrote:
>>>>> Agile software development is an iterative, incremental approach to
>>>>> developing and releasing software. A range of agile methodologies have
>>>>> emerged and they are based frequent releases, ongoing testing,
>>>>> customer and stakeholder participation throughout the development
>>>>> process, co-ownership of code and pair-programming.
>>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>>
>>>>> 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.

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

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

#11986

On 2/12/2012 10:08 AM, Patricia Shanahan wrote:
> Arne Vajhøj wrote:
>> On 2/12/2012 1:43 AM, simplicity wrote:
>>> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk> wrote:
>>>> On 2/10/2012 11:26 AM, simplicity wrote:
>>>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>>>> <iqraeducationalpor...@gmail.com> wrote:
>>>>>> Agile software development is an iterative, incremental approach to
>>>>>> developing and releasing software. A range of agile methodologies
>>>>>> have
>>>>>> emerged and they are based frequent releases, ongoing testing,
>>>>>> customer and stakeholder participation throughout the development
>>>>>> process, co-ownership of code and pair-programming.
>>>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>>>
>>>>>> 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.
>
> I've also seen non-Agile projects with large overhead.

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

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

#11987

On 12-02-12 11:08 AM, Patricia Shanahan wrote:
> Arne Vajhøj wrote:
>> On 2/12/2012 1:43 AM, simplicity wrote:
>>> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk>  wrote:
>>>> On 2/10/2012 11:26 AM, simplicity wrote:
>>>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>>>> <iqraeducationalpor...@gmail.com>    wrote:
>>>>>> Agile software development is an iterative, incremental approach to
>>>>>> developing and releasing software. A range of agile methodologies
>>>>>> have
>>>>>> emerged and they are based frequent releases, ongoing testing,
>>>>>> customer and stakeholder participation throughout the development
>>>>>> process, co-ownership of code and pair-programming.
>>>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>>>
>>>>>> 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.
> 
> 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

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.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11989

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

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

#11990

On 2/12/2012 12:00 PM, Lew wrote:
> 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.

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

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

#11993

On 2/12/2012 12:06 PM, Arne Vajhøj wrote:
> On 2/12/2012 12:00 PM, Lew wrote:
>> 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.
>
> 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.

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

Arne

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

#12002

Arne Vajhøj wrote:
> Arne Vajhøj wrote:
> > Lew wrote:
> >> 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.
> >
> > 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.
> 
> Imagine some autonomous web UI projects choosing:
> - PHP
> - Struts
> - JSF
> and some autonomous persistence projects choosing:
> - Oracle with SP's
> - DB2 with Hibernate

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

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

#12003

On 2/12/2012 3:55 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> 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.
>>>
>>> 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.
>>
>> Imagine some autonomous web UI projects choosing:
>> - PHP
>> - Struts
>> - JSF
>> and some autonomous persistence projects choosing:
>> - Oracle with SP's
>> - DB2 with Hibernate
>
> 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.

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

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

#12004

On 2/12/2012 3:55 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> 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.
>>>
>>> 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.
>>
>> Imagine some autonomous web UI projects choosing:
>> - PHP
>> - Struts
>> - JSF
>> and some autonomous persistence projects choosing:
>> - Oracle with SP's
>> - DB2 with Hibernate
>
> 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.

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

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

#12008

Arne Vajhøj wrote:
> Lew wrote:
> > Arne Vajhøj wrote:
> >> Arne Vajhøj wrote:
> >>> Lew wrote:
> >>>> 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.
> >>>
> >>> 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.
> >>
> >> Imagine some autonomous web UI projects choosing:
> >> - PHP
> >> - Struts
> >> - JSF
> >> and some autonomous persistence projects choosing:
> >> - Oracle with SP's
> >> - DB2 with Hibernate
> >
> > 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.
> 
> 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.

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

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

#12101

On 2/12/2012 8:04 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> Arne Vajhøj wrote:
>>>>> Lew wrote:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> Imagine some autonomous web UI projects choosing:
>>>> - PHP
>>>> - Struts
>>>> - JSF
>>>> and some autonomous persistence projects choosing:
>>>> - Oracle with SP's
>>>> - DB2 with Hibernate
>>>
>>> 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.
>>
>> 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.
>
> 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.

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

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

#12118

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

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

#11981

On 12-02-12 10:19 AM, Arne Vajhøj wrote:
> On 2/12/2012 1:43 AM, simplicity wrote:
>> On Feb 11, 4:05 pm, Arne Vajhøj<a...@vajhoej.dk>  wrote:
>>> On 2/10/2012 11:26 AM, simplicity wrote:
>>>> On Feb 8, 11:51 pm, Iqra Educational Portal
>>>> <iqraeducationalpor...@gmail.com>    wrote:
>>>>> Agile software development is an iterative, incremental approach to
>>>>> developing and releasing software. A range of agile methodologies have
>>>>> emerged and they are based frequent releases, ongoing testing,
>>>>> customer and stakeholder participation throughout the development
>>>>> process, co-ownership of code and pair-programming.
>>>>> iQRA’s Agile Exam will test your knowledge about Agile Development
>>>>> including XP, and SCRUM techniques in the light of Agile Manifesto
>>>
>>>>> 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
> 
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
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web