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

#11985

On 2/12/2012 10:43 AM, Arved Sandstrom wrote:
> 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.

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

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

#11991

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.

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

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

#11994

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

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

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

#11992

Arved Sandstrom <asandstrom3minus1@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

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

#12009

In article <92d0e832-6c70-4dc6-9c9f-71f588920d36@vv9g2000pbc.googlegroups.com>, simplicity <stella_pigeon@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

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

#12013

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.

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

#12014

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

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

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

#12015

Patricia Shanahan <pats@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

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

#12016

Leif Roar Moldskred wrote:
> Patricia Shanahan <pats@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.
> 

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

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

#12100

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

[toc] | [prev] | [standalone]

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

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

csiph-web