Call for participation: What types of organisations adopt agile methods?

Discussion in 'Java' started by Ant Grinyer, Jul 10, 2008.

  1. Ant Grinyer

    Ant Grinyer Guest

    Having worked in software development for over 15 years in many
    organisations using different development methodologies such as
    waterfall, RUP, Scrum and XP, I'm still not sure if there is a
    specific 'type' of organisation that is more likely to adopt agile
    approaches than others?

    I guess it could be argued that those organisations that are more
    innovative or open to change are more likely to adopt agile methods?

    To try and gain more understanding, and because I have a passion for
    software development methodologies, I started a PhD five years ago
    (part-time) to look at this issue. I'm now at the point where I'm
    conducting a short survey to determine what factors might or might not
    influence the adoption of agile methods, in the hope to provide some
    enlightenment. If we get enough participation, I then hope to report
    this back to the group to see if there are indeed any trends.

    The survey is short and should take around 5 - 10 minutes to complete,
    so please bare with the scaled questions whereby you are asked to rate
    your agreement against a list of statements. To participate, could I
    kindly ask you to fill in the survey using the link below -

    http://ou1211237011.agile-adoption.sgizmo.com

    I believe if we can determine the characteristics of organisations
    that adopt and do not adopt agile methods, we can get a better
    understanding whether certain organisations are more conducive to
    adopting agile methods?

    Note this is NOT a marketing survey and is used for doctoral and
    practitioner research purposes. All findings and results will be
    published to the group and responses treated in strict confidence.
    Evidence of my research can be found here:

    http://www.computing.open.ac.uk/Pub...439004E6A1F?OpenDocument&subsection=computing


    Your participation is greatly appreciated.
    Kindest Regards
    Ant Grinyer
    ----------
    Business Analyst | Cegedim Pharmaceutical Solutions, UK
    PhD Candidate | The Open University | Milton Keynes, UK
     
    Ant Grinyer, Jul 10, 2008
    #1
    1. Advertising

  2. Ant Grinyer

    James Kanze Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Jul 10, 11:33 pm, (Ant Grinyer) wrote:
    > Having worked in software development for over 15 years in
    > many organisations using different development methodologies
    > such as waterfall, RUP, Scrum and XP, I'm still not sure if
    > there is a specific 'type' of organisation that is more likely
    > to adopt agile approaches than others?


    > I guess it could be argued that those organisations that are
    > more innovative or open to change are more likely to adopt
    > agile methods?


    It could just as easily be argued that those organisations care
    less about quality and robustness. Or don't have to worry about
    a budget. Or are easily taken in by fancy advertising words,
    rather than substance.

    "Agile programming", as such, doesn't mean anything. It's just
    a positive sounding buzz word, which anyone developing a new
    methodology applies to make it sound good.

    Note that the expression "waterfall methodology" doesn't apply
    to any definite methodology either. It's just the opposite of
    agile programming, a negative sounding buzz word to apply to
    those who don't buy into your new methodology.

    Neither correspond to any single, well defined methodology.
    Roughly speaking: if I do it, it's agile programming, but if
    someone else does it, it's waterfall.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #2
    1. Advertising

  3. "James Kanze" <> wrote in message
    news:...
    On Jul 10, 11:33 pm, (Ant Grinyer) wrote:
    > Having worked in software development for over 15 years in
    > many organisations using different development methodologies
    > such as waterfall, RUP, Scrum and XP, I'm still not sure if
    > there is a specific 'type' of organisation that is more likely
    > to adopt agile approaches than others?


    > I guess it could be argued that those organisations that are
    > more innovative or open to change are more likely to adopt
    > agile methods?


    It could just as easily be argued that those organisations care
    less about quality and robustness. Or don't have to worry about
    a budget. Or are easily taken in by fancy advertising words,
    rather than substance.

    "Agile programming", as such, doesn't mean anything. It's just
    a positive sounding buzz word, which anyone developing a new
    methodology applies to make it sound good.

    Note that the expression "waterfall methodology" doesn't apply
    to any definite methodology either. It's just the opposite of
    agile programming, a negative sounding buzz word to apply to
    those who don't buy into your new methodology.

    Neither correspond to any single, well defined methodology.
    Roughly speaking: if I do it, it's agile programming, but if
    someone else does it, it's waterfall.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

    ********************************************

    I'd also argue that in a number of situations the waterfall model is either
    just as acceptable as any other, or even to be preferred. Waterfall
    methodology does mean something specific: the purely sequential model.

    By and large, in situations where I've seen the sequential model struggle or
    fail, it's because the organisation was incompetent at gathering
    requirements and/or not able to resist pressure (both external or internal)
    to change requirements during the process. This is frequently accompanied by
    a lack of discipline, and usually pretty lackluster software development
    processes overall - makes one wonder if the sequential model isn't
    frequently blamed by organizations that couldn't successfully develop with
    *any* model.

    Software developers do (or should) use the sequential process fairly
    frequently. For example, if a client gave you a clear set of requirements
    for a project that is going to require a man-month or less (for sake of
    example) I'd be hard-pressed to argue that this project would require
    something other than purely sequential. Go ahead and use something else if
    you like - just don't tell me that sequential wouldn't work.

    For a bigger project - maybe in particular some of the biggest projects -
    the sequential model could well be advisable. Some of the criticisms of the
    process are valid, such as some implementation details may not become known
    until coding time (as in, "none of these bleeding-edge technologies actually
    work"), or it may be very difficult to resist client demands for
    requirements changes. However, a lot of the time the criticisms of pure
    sequential boil down to this: less-than-excellent organizations find it
    difficult to do. Or to put it another way, if your organization is mediocre,
    go for a methodology that tolerates mediocrity more robustly.

    Call me cynical.

    AHS
     
    Arved Sandstrom, Jul 11, 2008
    #3
  4. Ant Grinyer

    Tom Anderson Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Fri, 11 Jul 2008, James Kanze wrote:

    > On Jul 10, 11:33 pm, (Ant Grinyer) wrote:
    >
    >> Having worked in software development for over 15 years in
    >> many organisations using different development methodologies
    >> such as waterfall, RUP, Scrum and XP, I'm still not sure if
    >> there is a specific 'type' of organisation that is more likely
    >> to adopt agile approaches than others?

    >
    >> I guess it could be argued that those organisations that are
    >> more innovative or open to change are more likely to adopt
    >> agile methods?

    >
    > It could just as easily be argued that those organisations care
    > less about quality and robustness. Or don't have to worry about
    > a budget. Or are easily taken in by fancy advertising words,
    > rather than substance.
    >
    > "Agile programming", as such, doesn't mean anything. It's just a
    > positive sounding buzz word, which anyone developing a new methodology
    > applies to make it sound good.


    No, agile has a very well-defined meaning. It's what used to be called
    Extreme Programming, which is based on a set of commandments recorded by
    St Kent of Beck. They had to change the name because it was putting people
    off.

    And if you think that agile produces software of lower quality and
    robustness than traditional methods, i think you need to lay off the
    mushrooms for a bit.

    > Neither correspond to any single, well defined methodology. Roughly
    > speaking: if I do it, it's agile programming, but if someone else does
    > it, it's waterfall.


    You may be quite right about people using 'agile' as a buzzword to mean
    anything and nothing, but that's a misuse of the term.

    tom

    --
    20 Minutes into the Future
     
    Tom Anderson, Jul 11, 2008
    #4
  5. Ant Grinyer

    Tom Anderson Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Fri, 11 Jul 2008, Arved Sandstrom wrote:

    > By and large, in situations where I've seen the sequential model
    > struggle or fail, it's because the organisation was incompetent at
    > gathering requirements and/or not able to resist pressure (both external
    > or internal) to change requirements during the process.


    Absolutely. Changing requirements is what kills waterfall. And the problem
    is that *that happens*. Gathering perfect requirements upfront is
    spectacularly hard, and often probably entirely impossible, because it
    involves an understanding of how the system will interact with existing
    products and processes that can't be determined without actually seeing
    it. On top of that, the client's needs may genuinely change during the
    liftime of the project.

    Okay, so maybe you could put enough time, energy and intelligence into
    requirements gathering that you could apply waterfall. But why not just
    adopt a methodology that doesn't require you to do that? Using agile means
    that you can easily adapt to changes in requirements, so you can just
    forget all that up-front stuff.

    > This is frequently accompanied by a lack of discipline, and usually
    > pretty lackluster software development processes overall - makes one
    > wonder if the sequential model isn't frequently blamed by organizations
    > that couldn't successfully develop with *any* model.


    This strikes me as very likely to be true.

    There's an old XP get-out here, though, which is to say that in these
    cases, the developers aren't truly following XP. Doing XP means, amongst
    other things, having unit tests for everything, keeping the system
    well-factored, and sticking religiously to implementing fine-grained,
    well-defined requirements. If you do that, it works, and you *will*
    deliver good software. If you don't, it doesn't - but then you aren't
    *really* doing XP.

    > Software developers do (or should) use the sequential process fairly
    > frequently. For example, if a client gave you a clear set of
    > requirements for a project that is going to require a man-month or less
    > (for sake of example) I'd be hard-pressed to argue that this project
    > would require something other than purely sequential. Go ahead and use
    > something else if you like - just don't tell me that sequential wouldn't
    > work.


    Agreed. In fact, for a project of that scale, agile and waterfall become
    largely degenerate, and both involve doing much the same things. Capture
    the requirements, figure out how to test it, write the code.

    The difference only emerges on longer projects - waterfall stretches each
    phase to be longer, agile keeps the same phase length, and splits the
    project into iterations.

    > For a bigger project - maybe in particular some of the biggest projects
    > - the sequential model could well be advisable. Some of the criticisms
    > of the process are valid, such as some implementation details may not
    > become known until coding time (as in, "none of these bleeding-edge
    > technologies actually work"), or it may be very difficult to resist
    > client demands for requirements changes. However, a lot of the time the
    > criticisms of pure sequential boil down to this: less-than-excellent
    > organizations find it difficult to do.


    Exactly. That's the whole point! The vast majority of organisations are
    less than excellent, by definition, so a methodology that requires heroic
    geniuses to work isn't very useful in the real world.

    > Or to put it another way, if your organization is mediocre, go for a
    > methodology that tolerates mediocrity more robustly.


    And that's why i work in an agile shop!

    tom

    --
    20 Minutes into the Future
     
    Tom Anderson, Jul 11, 2008
    #5
  6. Ant Grinyer

    James Kanze Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Jul 11, 1:26 pm, Lew <> wrote:
    > (Ant Grinyer) wrote:
    > >> I guess it could be argued that those organisations that are
    > >> more innovative or open to change are more likely to adopt
    > >> agile methods?

    > James Kanze wrote:
    > > It could just as easily be argued that those organisations care
    > > less about quality and robustness. Or don't have to worry about
    > > a budget. Or are easily taken in by fancy advertising words,
    > > rather than substance.


    > This shows a lack of research into or understanding of what
    > the proponents of agile programming are promoting.


    Or too much research. Every one I've read is promoting
    something different.

    > > "Agile programming", as such, doesn't mean anything. It's just
    > > a positive sounding buzz word, which anyone developing a new
    > > methodology applies to make it sound good.


    > Again, you have failed to understand what people are saying.
    > "Agile programming" is a rubric for a particular approach to
    > software project management.


    Yes, the one the particular person using the phrase is
    promoting. It's become a Humpty-Dumpty word, like OO (or to a
    much less degree, generic programming).

    > > Note that the expression "waterfall methodology" doesn't apply
    > > to any definite methodology either. It's just the opposite of


    > Waterfall has been around for almost fifty years, long enough
    > for people to understand that it refers also to a specific set
    > of development principles. The term is broad, yes, but not
    > just


    > > a negative sounding buzz word to apply to
    > > those who don't buy into your new methodology.


    > In fact, the term "waterfall" for software development
    > predates "your new methodology" by decades, so it is more than
    > a little disingenuous to blame the agile programming world for
    > that term.


    Sorry, you're just plain wrong there. Bad development processes
    have been around for ages (and are still around), but the only
    uses of the term "waterfall methodology" that I've been able to
    find have been as strawmen.

    I'm not saying that no organization has used what looks like
    what the advocates of other methodologies present as
    "waterfall". But it's never been described and presented as a
    good development methodology. No one has ever "adopted"
    waterfall methodology. And of course, some of the techniques
    I've seen used by people claiming to be using "agile" methods
    have been just as bad.

    > > Neither correspond to any single, well defined methodology.
    > > Roughly speaking: if I do it, it's agile programming, but if
    > > someone else does it, it's waterfall.


    > That is inaccurate. For those who want to know, googling will
    > reveal the truth.


    Yup. It will reveal an incredible number of different
    definitions of "agile programming".

    As far as the name of a methodology goes, of course, it's pure
    advertising. It doesn't really say anything about the
    methodology. It's just a positive sounding phrase to suggest
    that the methodology has some particular positive
    characteristic, and to imply by intuendo that other
    methodologies don't. (Program methodologies have been "agile"
    since programming began, and arguably, the most agile method
    around is that of the "real programmer", the isolated genius who
    has everything in his head, and can rewrite all of the code in
    no time.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #6
  7. Ant Grinyer

    James Kanze Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Jul 11, 3:00 pm, Tom Anderson <> wrote:
    > On Fri, 11 Jul 2008, James Kanze wrote:
    > > On Jul 10, 11:33 pm, (Ant Grinyer) wrote:


    [...]
    > > "Agile programming", as such, doesn't mean anything. It's
    > > just a positive sounding buzz word, which anyone developing
    > > a new methodology applies to make it sound good.


    > No, agile has a very well-defined meaning. It's what used to
    > be called Extreme Programming, which is based on a set of
    > commandments recorded by St Kent of Beck. They had to change
    > the name because it was putting people off.


    That's one definition. (Not that extreme programming is any
    more exact---what it means depend on who you are reading.)

    > And if you think that agile produces software of lower quality
    > and robustness than traditional methods, i think you need to
    > lay off the mushrooms for a bit.


    Most of the techniques I've seen associated with it do produce
    software with measurably lower quality and robustness than the
    best current practice. (But of course, if you're "agile", you
    don't take the time to measure, so you don't know this.)

    > > Neither correspond to any single, well defined methodology.
    > > Roughly speaking: if I do it, it's agile programming, but if
    > > someone else does it, it's waterfall.


    > You may be quite right about people using 'agile' as a
    > buzzword to mean anything and nothing, but that's a misuse of
    > the term.


    The problem then is that it has been misused so often that it's
    lost any real meaning. Or perhaps the real problem is that
    people like Kent Beck didn't choose a more descriptive name.
    Although I'm not sure that's a fundamental reason. Something
    like "software maturity model" also has a very positive buzz,
    without really saying anything, but at least at present, I've
    only seen it really applied to one particular methodology.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #7
  8. Ant Grinyer

    James Kanze Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Jul 11, 2:36 pm, Patricia Shanahan <> wrote:
    > Ant Grinyer wrote:
    > > Having worked in software development for over 15 years in
    > > many organisations using different development methodologies
    > > such as waterfall, RUP, Scrum and XP, I'm still not sure if
    > > there is a specific 'type' of organisation that is more
    > > likely to adopt agile approaches than others?


    > > I guess it could be argued that those organisations that are
    > > more innovative or open to change are more likely to adopt
    > > agile methods?


    > Surely the methodology should be chosen to fit the project,
    > not fixed for the organization. I know that I use different
    > methodologies depending on what I am doing.


    > Maybe an organization that does not adopt agile methods is
    > just doing a lot of projects they do not suit.


    In other words, they're being agile:).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #8
  9. Ant Grinyer

    Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    James Kanze <> wrote:
    > On Jul 11, 3:00 pm, Tom Anderson <> wrote:
    >
    > > On Fri, 11 Jul 2008, James Kanze wrote:
    > > > On Jul 10, 11:33 pm, (Ant Grinyer) wrote:


    > Most of the techniques I've seen associated with it do produce
    > software with measurably lower quality and robustness than the
    > best current practice.  (But of course, if you're "agile", you
    > don't take the time to measure, so you don't know this.)


    This again shows that you really have not taken the time to understand
    what the "agile" folks espouse. Measurement and testing are the heart
    of the technique. That you say otherwise betrays your ignorance.

    As for not seeing the term "waterfall" prior to the promulgation of
    the "agile" buzzword, you again show ignorance. I was taught the
    "waterfall" method by that name in the late 1970s and early 80s by
    people who believe in its efficacy.

    >>> Neither correspond to any single, well defined methodology.


    Again, for folks who want the truth, don't buy into the nonsense and
    straw-man arguments James Kanze presents. Do the research yourself.
    GIYF. James Kanze is just trolling.

    --
    Lew
     
    , Jul 11, 2008
    #9
  10. Ant Grinyer

    James Kanze Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Jul 11, 6:43 pm, wrote:
    > James Kanze <> wrote:
    > > On Jul 11, 3:00 pm, Tom Anderson <> wrote:


    > > > On Fri, 11 Jul 2008, James Kanze wrote:
    > > > > On Jul 10, 11:33 pm, (Ant Grinyer) wrote:

    > > Most of the techniques I've seen associated with it do produce
    > > software with measurably lower quality and robustness than the
    > > best current practice. (But of course, if you're "agile", you
    > > don't take the time to measure, so you don't know this.)


    > This again shows that you really have not taken the time to
    > understand what the "agile" folks espouse. Measurement and
    > testing are the heart of the technique. That you say
    > otherwise betrays your ignorance.


    Or maybe that I've read more about it than you have, and thus
    have seen the numerous contrasting (and contradictory) claims.
    And measurement is certainly NOT part of what Kent Beck
    describes.

    > As for not seeing the term "waterfall" prior to the promulgation of
    > the "agile" buzzword, you again show ignorance. I was taught the
    > "waterfall" method by that name in the late 1970s and early 80s by
    > people who believe in its efficacy.


    Could you cite some references. Because I've talked to a lot of
    people, and no one else seems to have ever seen it described,
    except to compare their "better" method against.

    > >>> Neither correspond to any single, well defined methodology.


    > Again, for folks who want the truth, don't buy into the nonsense and
    > straw-man arguments James Kanze presents. Do the research yourself.
    > GIYF. James Kanze is just trolling.


    Well, anyone who looks it up on Google, with an open mind, is
    bound to come to the same conclusion I did.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 11, 2008
    #10
  11. Ant Grinyer

    Timo Geusch Guest

    Re: Call for participation: What types of organisations adopt agile methods?

    James Kanze <> writes:

    > On Jul 11, 6:43 pm, wrote:
    >> As for not seeing the term "waterfall" prior to the promulgation of
    >> the "agile" buzzword, you again show ignorance. I was taught the
    >> "waterfall" method by that name in the late 1970s and early 80s by
    >> people who believe in its efficacy.

    >
    > Could you cite some references. Because I've talked to a lot of
    > people, and no one else seems to have ever seen it described,
    > except to compare their "better" method against.


    I'm pretty sure Steve McConnell mentioned it in the first edition of
    Code Complete back in the early/mid nineties. Unfortunately I've since
    replaced it with the second edition so I can't verify this.
     
    Timo Geusch, Jul 11, 2008
    #11
  12. "Tom Anderson" <> wrote in message
    news:p...
    > On Fri, 11 Jul 2008, Arved Sandstrom wrote:
    >
    >> By and large, in situations where I've seen the sequential model struggle
    >> or fail, it's because the organisation was incompetent at gathering
    >> requirements and/or not able to resist pressure (both external or
    >> internal) to change requirements during the process.

    >
    > Absolutely. Changing requirements is what kills waterfall. And the problem
    > is that *that happens*. Gathering perfect requirements upfront is
    > spectacularly hard, and often probably entirely impossible, because it
    > involves an understanding of how the system will interact with existing
    > products and processes that can't be determined without actually seeing
    > it. On top of that, the client's needs may genuinely change during the
    > liftime of the project.


    Or the client may not understand his needs fully until he sees a tangible
    expression of them, i.e. something developed as part of a later phase. And
    when you're developing a commercial product where the client is "the
    market", this is guaranteed to be true.
     
    Mike Schilling, Jul 11, 2008
    #12
  13. Ant Grinyer

    Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    wrote:
    > >> As for not seeing the term "waterfall" prior to the promulgation of
    > >> the "agile" buzzword, you again show ignorance.  I was taught the
    > >> "waterfall" method by that name in the late 1970s and early 80s by
    > >> people who believe in its efficacy.


    James Kanze writes:
    > > Could you cite some references.  Because I've talked to a lot of
    > > people, and no one else seems to have ever seen it described,
    > > except to compare their "better" method against.


    Have you considered googling for it?

    /Wicked Problems, Righteous Solutions/ gives a good overview of all
    the software-development methodologies extant in the mid-nineties,
    with a thorough analysis of their strengths and weaknesses. It
    predates "XP" and "agile".

    <http://www.google.com/search?q="Wicked+Problems%2C+Righteous
    +Solutions">

    Other references: GIYF.

    I am a reference, because my comments were based on my own personal
    work experience. Shops where I worked in 1980-1981 practiced
    waterfall development, ostensibly, and called it by that name.

    Timo Geusch wrote:
    > I'm pretty sure Steve McConnell mentioned it in the first edition of
    > Code Complete back in the early/mid nineties. Unfortunately I've since
    > replaced it with the second edition so I can't verify this.


    GIYF, James Kanze,

    --
    Lew
     
    , Jul 11, 2008
    #13
  14. Ant Grinyer

    Ian Collins Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    James Kanze wrote:
    >
    > Most of the techniques I've seen associated with it do produce
    > software with measurably lower quality and robustness than the
    > best current practice. (But of course, if you're "agile", you
    > don't take the time to measure, so you don't know this.)
    >

    Oh come on James, that's just not true. I have a number of XP developed
    embedded products in the wild and by any measure the company uses, they
    are the most robust products the company has ever shipped. Our main
    measure was the only one that matters to our customers, defect reports.
    The number has been vanishingly small, a small fraction of the number
    for the previous generation controllers.

    If you are an XP team supporting a buggy product, your most important
    and visible measure - velocity will suffer.

    > The problem then is that it has been misused so often that it's
    > lost any real meaning. Or perhaps the real problem is that
    > people like Kent Beck didn't choose a more descriptive name.


    Now here we agree!

    --
    Ian Collins.
     
    Ian Collins, Jul 11, 2008
    #14
  15. "Tom Anderson" <> wrote in message
    news:p...
    > On Fri, 11 Jul 2008, Arved Sandstrom wrote:
    >
    >> By and large, in situations where I've seen the sequential model struggle
    >> or fail, it's because the organisation was incompetent at gathering
    >> requirements and/or not able to resist pressure (both external or
    >> internal) to change requirements during the process.

    >
    > Absolutely. Changing requirements is what kills waterfall. And the problem
    > is that *that happens*. Gathering perfect requirements upfront is
    > spectacularly hard, and often probably entirely impossible, because it
    > involves an understanding of how the system will interact with existing
    > products and processes that can't be determined without actually seeing
    > it. On top of that, the client's needs may genuinely change during the
    > liftime of the project.
    >
    > Okay, so maybe you could put enough time, energy and intelligence into
    > requirements gathering that you could apply waterfall. But why not just
    > adopt a methodology that doesn't require you to do that? Using agile means
    > that you can easily adapt to changes in requirements, so you can just
    > forget all that up-front stuff.

    [ SNIP ]

    All this sort of implies that it's not the software development
    organization's fault that requirements change so much. Perhaps you didn't
    mean it that way, but it reads that way. In actual fact, more often than
    not, those "changed" requirements aren't "changed" at all - it's just that
    nobody in the software team asked the right questions, or understood the
    answers, or even had the business domain background to really have a hope of
    understanding the answers.

    Yes, gathering requirements upfront is hard, but it's not spectacularly
    hard. I've been on enough projects where, if a postmortem were to take
    place, you could truthfully say "yes, in hindsight, the client was telling
    us they wanted that feature from Day One, and we assumed we knew what they
    meant". Or "yes, in hindsight, we knew right at the start that we didn't
    know how the client did a certain process, and we never asked, we just made
    some more assumptions". Or, "we knew all along that the client followed a
    certain process to do Task X - we decided that we knew better, and invented
    a new process...gee, the client didn't like that".

    Are there genuine changes in client's needs? Sure. And there should be a
    mechanism in place to manage that. But my argument is, a lot of these
    requirements "changes" are nothing of the sort: they are corrections of
    mistakes, or just "discovering" a requirement for the first time. If a
    business analyst (assuming you even bothered to employ a credible number of
    business analysts during the requirements gathering phase, if any) comes to
    you (wearing the team lead or project manager hat) later, and says "look, we
    sat down with the guy in charge of delivery drivers, plus one of the guys
    who schedules drivers, plus we spent a week on the routes with drivers,
    everyone of them said that this is how they do this certain thing, we have
    sign-off that they didn't want to change how the thing was done, and now
    they're changing how drivers do a part of their job", _that's_ a
    requirements change. Again, there are mechanisms in place to handle this.

    In the above scenario, what's _not_ a requirements change is if you had no
    real business analysis done, and so never really knew exactly what it was
    that the client's delivery drivers did. You did know, in effect, what the
    impact was on inventory after a day's deliveries, but you didn't analyze the
    driver workflow in detail. So you decide that you, as programmers, can
    invent a better workflow. A few months down the road, having coded up a
    beautiful solution, you present it to the client, and the drivers say "well,
    hell, I don't mind using this electronic gizmo instead of paper, but I can't
    do anything in the order I'm used to doing it, and I can't find any place to
    put in some of the information, and what's up with this new information I
    have to put in?" And guess what? The end users rebel. When you now apply
    your agile programming to change your code, you're not adapting to a
    changing requirement - you're fixing a mistake.

    I'm not advocating strict waterfall for most situations. I'm mostly playing
    devil's advocate here. My basic argument is this: you _can_ do effective
    requirements gathering: I've seen it done, and in challenging environments.
    It just won't be perfect. It doesn't need to be perfect. But under no
    circumstances is it acceptable to design and implement on the basis of
    missing or imperfect knowledge of requirements. And my contention is that a
    lot of these "changing" requirements that programmers gamely cope with are
    simply poor requirements gathering. In any case, if your organization is
    relatively crappy at gathering requirements up front, why is it going to be
    better at doing so later in the project?

    AHS
     
    Arved Sandstrom, Jul 13, 2008
    #15
  16. Ant Grinyer

    Tom Anderson Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Sun, 13 Jul 2008, Arved Sandstrom wrote:

    > "Tom Anderson" <> wrote in message
    > news:p...
    >> On Fri, 11 Jul 2008, Arved Sandstrom wrote:
    >>
    >>> By and large, in situations where I've seen the sequential model struggle
    >>> or fail, it's because the organisation was incompetent at gathering
    >>> requirements and/or not able to resist pressure (both external or
    >>> internal) to change requirements during the process.

    >>
    >> Absolutely. Changing requirements is what kills waterfall. And the problem
    >> is that *that happens*.

    >
    > All this sort of implies that it's not the software development
    > organization's fault that requirements change so much. Perhaps you
    > didn't mean it that way, but it reads that way.


    I did mean that.

    > In actual fact, more often than not, those "changed" requirements aren't
    > "changed" at all - it's just that nobody in the software team asked the
    > right questions, or understood the answers, or even had the business
    > domain background to really have a hope of understanding the answers.


    And i also meant that!

    You're right that a lot of the apparent change is due to a changing
    understanding of the requirements, mediated by both a failure of the
    software team to get it, and of the client to really understand their own
    needs. And yes, by putting a large amount of effort in here, you can
    reduce the understanding gap and get better requirements.

    But doing requirements gathering iteratively means that you don't need to
    expend that effort.

    > Yes, gathering requirements upfront is hard, but it's not spectacularly
    > hard.


    I think this is where we differ. Difficulty is something that's rather
    hard (!) to express quantitatively, so we could sit here all week trading
    expressions of hardness, but i think your assertion is that gathering
    adequate requirements upfront is not too hard to get right routinely
    without expending major effort, whereas my assertion is that it is. My
    impression is that the experience of the software industry as a whole is
    on my side, but i have to confess that i can't cite data on this, so i'm
    really just talking about impressions.

    > I've been on enough projects where, if a postmortem were to take place,
    > you could truthfully say "yes, in hindsight, the client was telling us
    > they wanted that feature from Day One, and we assumed we knew what they
    > meant". Or "yes, in hindsight, we knew right at the start that we didn't
    > know how the client did a certain process, and we never asked, we just
    > made some more assumptions". Or, "we knew all along that the client
    > followed a certain process to do Task X - we decided that we knew
    > better, and invented a new process...gee, the client didn't like that".
    >
    > [snip bit about genuine requirements change, where we agree, i think]
    >
    > In the above scenario, what's _not_ a requirements change is if you had
    > no real business analysis done, and so never really knew exactly what it
    > was that the client's delivery drivers did. You did know, in effect,
    > what the impact was on inventory after a day's deliveries, but you
    > didn't analyze the driver workflow in detail. So you decide that you, as
    > programmers, can invent a better workflow. A few months down the road,
    > having coded up a beautiful solution, you present it to the client, and
    > the drivers say "well, hell, I don't mind using this electronic gizmo
    > instead of paper, but I can't do anything in the order I'm used to doing
    > it, and I can't find any place to put in some of the information, and
    > what's up with this new information I have to put in?" And guess what?
    > The end users rebel. When you now apply your agile programming to change
    > your code, you're not adapting to a changing requirement - you're fixing
    > a mistake.


    I certainly agree with that - if you're implementing stuff the client
    hasn't asked for, you're doing it wrong.

    But i don't think an agile team is any more likely to invent wonderful new
    ways of screwing things up than a waterfall team. In fact, i think they're
    less likely, because of two or three things.

    Firstly, the emphasis on implementing small quanta of functionality
    derived directly and immediately from requirements expressed by the
    clients ('user stories' - not a term i like at all, but there you go). If
    the user hasn't written a story that says "do driver workflow in this new
    and exciting way", then an agile team won't implement it. The maintenance
    of a close link between requirements and implementation under agile really
    reduces the scope for programmers getting too clever.

    Secondly, the use of short iterations with frequent releases to the
    client. If the team does manage to get clever and do something unhelpful,
    the client finds out about and starts complaining very quickly, within
    weeks, so you have time to get it right there and then before it becomes
    too ingrained in the system. Because of the first point, this shouldn't
    happen too often. But this step is very useful in catching requirements
    that were wrong in the first place, whether because of a misunderstanding
    between client and team, or because the client didn't understand things
    clearly themselves.

    Thirdly, in orthodox XP teams, the presence of an on-site customer, who
    can act as a lighthouse for the team to steer by. If a programmer is
    sitting there and thinking "hmm, how do i structure the workflow?", and
    doesn't have any captured requirements explaining it, then rather than
    making something up, he can has the on-site customer. However, my
    impression is that relatively few agile teams manage to do this element of
    XP - it's just too hard to persuade the customer to go along with it. In
    that case, hopefully, a good project/product manager can get an answer
    from the client quickly instead

    I should perhaps amplify the point that agile is not about avoiding
    requirements-gathering. Rather, it recognises it as an extremely important
    step, and has a procedure for doing it. Indeed, the use of user stories
    directly as implementation tasks makes the link between requirements and
    implementation even more immediate than in conventional processes, where
    you have a flow from requirements to analysis to architecture, and then to
    implementation. You're not writing code based on what your architect
    interpreted the requirements written by your business analyst to mean,
    you're writing it based on what the customer wrote on a piece of card with
    his own hand.

    Now, helping the client to really understand his own needs, so he can
    write the right thing, is not trivial, and that is somewhere where, as far
    as i know, agile doesn't have any clever tricks. You just have to do the
    same things as a waterfall team would do, and spend time talking and
    asking questions. The agile advantage is that you only have to do this in
    small chunks, so if there is a shortcoming, its effect is limited.

    > I'm not advocating strict waterfall for most situations. I'm mostly
    > playing devil's advocate here. My basic argument is this: you _can_ do
    > effective requirements gathering: I've seen it done, and in challenging
    > environments. It just won't be perfect. It doesn't need to be perfect.
    > But under no circumstances is it acceptable to design and implement on
    > the basis of missing or imperfect knowledge of requirements. And my
    > contention is that a lot of these "changing" requirements that
    > programmers gamely cope with are simply poor requirements gathering.


    Doubtless right. And agilists agree with you entirely on that.

    > In any case, if your organization is relatively crappy at gathering
    > requirements up front, why is it going to be better at doing so later in
    > the project?


    Because gathering large quantities of accurate requirements up front is
    much harder than gathering small quantities incrementally.

    tom

    --
    THE DRUMMER FROM DEF LEPPARD'S ONLY GOT ONE ARM!
     
    Tom Anderson, Jul 13, 2008
    #16
  17. Re: Call for participation: What types of organisations adopt agilemethods?

    Tom Anderson wrote:
    > On Sun, 13 Jul 2008, Arved Sandstrom wrote:
    >

    ....
    >> In actual fact, more often than not, those "changed" requirements
    >> aren't "changed" at all - it's just that nobody in the software team
    >> asked the right questions, or understood the answers, or even had the
    >> business domain background to really have a hope of understanding the
    >> answers.

    >
    > And i also meant that!
    >
    > You're right that a lot of the apparent change is due to a changing
    > understanding of the requirements, mediated by both a failure of the
    > software team to get it, and of the client to really understand their
    > own needs. And yes, by putting a large amount of effort in here, you can
    > reduce the understanding gap and get better requirements.

    ....

    I think this varies a lot from project to project. Here are two examples
    of projects I've worked on:

    1. In the early 1980's, I was compiler writer for a small start up
    company that was building a UNIX-based workstation using a processor for
    which no C compiler existed. My first objective was to produce a
    functionally correct C cross-compiler running on a VAX producing code
    for the processor. It had to be able to handle the features used in a
    specific UNIX source code distribution.

    The requirements and schedule for that project could not change without
    a major rewrite of the company's business plan. On the other hand, it
    was very important to know whether I was on track to achieve the overall
    objective on schedule, so that we could take corrective action if I fell
    behind. That led to a detailed plan for the whole project, with
    milestones in terms of what programs the compiler should handle, that I
    could measure and report on. The first step was a high level design
    phase in which I made decisions based on the complete set of requirements.

    2. I am now a Ph.D. student doing research into applying machine
    learning to a ubiquitous computing project. I use a program I am writing
    both to get results and to inspire new questions. I do not know what the
    requirements will be in a few weeks time. I hope I will have thought of
    some new questions by then, leading to new requirements.

    Those are extreme cases, but the point is that the extent to which it is
    possible to know requirements in advance does vary, and I believe that
    is one of the issues that should affect the development process.

    Patricia
     
    Patricia Shanahan, Jul 13, 2008
    #17
  18. Re: Call for participation: What types of organisations adopt agilemethods?

    Lew wrote:
    > Tom Anderson wrote:
    >> I certainly agree with that - if you're implementing stuff the client
    >> hasn't asked for, you're doing it wrong.

    >
    > While generally I endorse Tom's reasoning, I have to disagree here.
    > Most of the time one must implement things the client hasn't asked for,
    > if one is to implement what the client wants. More than once I have
    > been the hero for having heard what's wanted between the lines of what's
    > requested.
    >
    > The whole business about requirements gathering is human-to-human
    > communication. To blithely assert that there's nothing wrong with the
    > methodology, people just need to communicate better, is to be either
    > disingenuous or naive. People do not communicate better. Methodologies
    > that deal with the reality of that do better because they aren't
    > Pollyanna-head-in-the-sand-communism-would-work-if-only-people-were-generous
    > blind to the way things really are.


    There is a big difference related to what phase the project is in.

    If the project is still in requirements phase (or even design phase
    if it is a flexible methodology), then it is fine to ask the customer
    "you wanted X, but it is really useless without Y, do you want Y ?" and
    update requirements appropriately.

    But it is very bad to add functionality without getting it in the
    requirements and it is always a risk to change things late in the
    project.

    Functionality that is not in the requirements will typical:
    * not be costed
    * not be tested
    which is very bad.

    > Also, clients change their mind, and you can be the victim of your own
    > success. If you do give them what they want, it triggers their
    > imagination and they immediately want a whole bunch more.


    It is a model that can end in disaster if Murphys law one day comes
    in play and it will certainly end in disaster the day the customer
    and the vendor get new people.

    > Agile techniques, buzzwordiness aside, deal with the reality that times,
    > ideas, opinions, knowledge and desire change over time, and that
    > communication is imperfect. Rather than pouting that people should be
    > better at requirements gathering up front, the agile outlook
    > acknowledges that we aren't, by dint of which it reduces the cost of
    > imperfect communication, formalizes the adaptation to new knowledge and
    > provides rapid feedback as to whether a project actually is doing what's
    > wanted, instead of waiting until millions have been spent to discover
    > the problem.


    Requirements change all the time for projects running over a long period
    of time.

    But the changes should always be documented and approved. Whether that
    involves creating a contract addendum of 200 pages or just that the
    customer project manager and vendor project manager spend 3 minutes
    on it at a standing morning meeting depends on the process used.

    Arne
     
    Arne Vajhøj, Jul 13, 2008
    #18
  19. "Patricia Shanahan" <> wrote in message
    news:g5d6l1$2j28$...
    > Tom Anderson wrote:
    >> On Sun, 13 Jul 2008, Arved Sandstrom wrote:
    >>

    > ...
    >>> In actual fact, more often than not, those "changed" requirements aren't
    >>> "changed" at all - it's just that nobody in the software team asked the
    >>> right questions, or understood the answers, or even had the business
    >>> domain background to really have a hope of understanding the answers.

    >>
    >> And i also meant that!
    >>
    >> You're right that a lot of the apparent change is due to a changing
    >> understanding of the requirements, mediated by both a failure of the
    >> software team to get it, and of the client to really understand their own
    >> needs. And yes, by putting a large amount of effort in here, you can
    >> reduce the understanding gap and get better requirements.

    > ...
    >
    > I think this varies a lot from project to project. Here are two examples
    > of projects I've worked on:
    >
    > 1. In the early 1980's, I was compiler writer for a small start up
    > company that was building a UNIX-based workstation using a processor for
    > which no C compiler existed. My first objective was to produce a
    > functionally correct C cross-compiler running on a VAX producing code
    > for the processor. It had to be able to handle the features used in a
    > specific UNIX source code distribution.
    >
    > The requirements and schedule for that project could not change without
    > a major rewrite of the company's business plan. On the other hand, it
    > was very important to know whether I was on track to achieve the overall
    > objective on schedule, so that we could take corrective action if I fell
    > behind. That led to a detailed plan for the whole project, with
    > milestones in terms of what programs the compiler should handle, that I
    > could measure and report on. The first step was a high level design
    > phase in which I made decisions based on the complete set of requirements.
    >
    > 2. I am now a Ph.D. student doing research into applying machine
    > learning to a ubiquitous computing project. I use a program I am writing
    > both to get results and to inspire new questions. I do not know what the
    > requirements will be in a few weeks time. I hope I will have thought of
    > some new questions by then, leading to new requirements.
    >
    > Those are extreme cases, but the point is that the extent to which it is
    > possible to know requirements in advance does vary, and I believe that
    > is one of the issues that should affect the development process.
    >
    > Patricia


    This makes me think that I have generally been confronted by projects -
    small through quite large - where for various reasons agile methods either
    are not really needed, or would not work for one reason or another. So my
    perspective on SDMs may be coloured by that.

    As an aside note, Kent Beck in "Extreme Programming Explained" mentions
    situations where XP won't work (or probably won't):

    1) wrong business culture - the client demands upfront requirements/design
    documents before coding starts. Not uncommon;

    2) size - large projects;

    3) technologies with inherently exponential cost curves;

    4) it takes a long time to get feedback through testing and QA.

    I realize that XP is not the same thing as agile, but the factors above
    probably influence the success of all agile SDMs. I can see point 1, in
    particular, being a major sticking point.

    AHS
     
    Arved Sandstrom, Jul 14, 2008
    #19
  20. Ant Grinyer

    Tom Anderson Guest

    Re: Call for participation: What types of organisations adopt agilemethods?

    On Mon, 14 Jul 2008, Arved Sandstrom wrote:

    > "Patricia Shanahan" <> wrote in message
    > news:g5d6l1$2j28$...
    >> Tom Anderson wrote:
    >>> On Sun, 13 Jul 2008, Arved Sandstrom wrote:
    >>>
    >>>> In actual fact, more often than not, those "changed" requirements
    >>>> aren't "changed" at all
    >>>
    >>> And yes, by putting a large amount of effort in here, you
    >>> can reduce the understanding gap and get better requirements.

    >>
    >> I think this varies a lot from project to project. Here are two examples
    >> of projects I've worked on:
    >>
    >> 1. In the early 1980's, I was compiler writer for a small start up
    >> company that was building a UNIX-based workstation using a processor for
    >> which no C compiler existed. My first objective was to produce a
    >> functionally correct C cross-compiler running on a VAX producing code
    >> for the processor. It had to be able to handle the features used in a
    >> specific UNIX source code distribution.
    >>
    >> The requirements and schedule for that project could not change without
    >> a major rewrite of the company's business plan. On the other hand, it
    >> was very important to know whether I was on track to achieve the overall
    >> objective on schedule, so that we could take corrective action if I fell
    >> behind. That led to a detailed plan for the whole project, with
    >> milestones in terms of what programs the compiler should handle, that I
    >> could measure and report on. The first step was a high level design
    >> phase in which I made decisions based on the complete set of requirements.
    >>
    >> Those are extreme cases, but the point is that the extent to which it is
    >> possible to know requirements in advance does vary, and I believe that
    >> is one of the issues that should affect the development process.

    >
    > This makes me think that I have generally been confronted by projects -
    > small through quite large - where for various reasons agile methods
    > either are not really needed, or would not work for one reason or
    > another. So my perspective on SDMs may be coloured by that.


    I'm really interested in this angle. I can certainly see that there can be
    projects where the requirements are easily knowable upfront, and thus
    where agile iterative requirements-gathering isn't needed. That is, where
    waterfall *would* work.

    What i don't know is whether an agile method *wouldn't* work in this
    situation.

    So, what is it about Patricia's compiler example that would mean that? Let
    me play agile zealot here ...

    Okay, so the requirements are fixed. No problem - you write them all on
    story cards at the start, and then the project manager (here acting as the
    client) negotiates a bunch of them with Agile Patricia every iteration.
    Agile Patricia can (must!) ignore the ones that she hasn't accepted for
    the current iteration, and just act as if the client was thinking them up
    in batches.

    Waterfall Patricia was able to draw up a big design upfront, based on the
    whole set of requirements. Agile Patricia would have to come up with an
    initial design based on the first batch of requirements, then evolve it in
    further iterations. That sounds bad. But the agile teaching is that (a) if
    you have well-factored code, the cost of changing a design is low
    (provided you don't have to change the whole 'system metaphor', aka
    architecture) and (b) you probably aren't going to get the design right
    up-front, so doing it incrementally is better anyway.

    A compiler is a bit of a funny case, in that compilers are extremely
    well-understood. If you've worked on a compiler before, you probably know
    exactly what you're doing, certainly in terms of architecture, and
    probably even in terms of somewhat more detailed organisation (unless
    you're intending to do something really radical, that is, but then all
    bets are off). That means both that you *can* get the design right up
    front, but also that a design chosen in the first iteration is likely to
    be right for the subsequent iterations too.

    The measurable milestones aspect is tougher, though. Waterfall Patricia
    had a list of which user stories would be implemented by which date, so
    that the project manager could man the pumps if they were missed. What
    would Agile Patricia have? Well, at the end of every iteration, she and
    the project manager would know if she'd managed to implement all the
    stories she'd signed up for, or alternatively if she'd done so within the
    deadline. That would be a readout of progress. But they wouldn't have any
    idea of the overall progress - that is, how much longer the rest of the
    system was going to take. To get that, you'd have to be able to accurately
    estimate all the stories at the start, and that would involve estimating
    based on building on top of a system which didn't exist at that point in
    time, which you can't do in agile.

    I guess the agilist's comeback to that is that you can't really do it in
    waterfall, either. You might think you can, but, they say, experience
    shows that such estimates turn out to be wrong. And if you're in a special
    situation, perhaps like a compiler, where you really can estimate them all
    at the start, then great. Do that, then drip-feed the requirements into an
    agile process. No, in that situation, you don't *have* to do agile, but it
    doesn't mean agile won't work. Although i suppose you could say that if
    you have all the requirements, and estimates for them, upfront, then
    you're not actually doing agile. I think if you were still doing pair
    programming, test-driven design, the simplest thing that could possibly
    work, merciless refactoring, continual integration and frequent releases,
    you could legitimately claim to be doing agile. But it would certainly be
    a different kind of agile.

    > As an aside note, Kent Beck in "Extreme Programming Explained" mentions
    > situations where XP won't work (or probably won't):
    >
    > 1) wrong business culture - the client demands upfront requirements/design
    > documents before coding starts. Not uncommon;
    >
    > 2) size - large projects;
    >
    > 3) technologies with inherently exponential cost curves;
    >
    > 4) it takes a long time to get feedback through testing and QA.


    These are all kind of pansy reasons, though. They're like the answers you
    give when an interviewer asks you what your biggest weakness is.

    Reason 1 is absolutely true, and highly important in practice, but it's
    kind of a meta-reason. People won't do agile because they don't think
    agile works. You can't say agile doesn't work because people won't do it!
    That's circular reasoning! Or are there cases where there are good
    external reasons for needing all the requirements or design docs upfront?
    Does requirements drip-feeding let you do agile in such an environment?

    Reason 2 is interesting, and one i really don't have a handle on. Couldn't
    you just split a large project up into subprojects, and run each with
    agile? Would the coordination have to be waterfall, or could that be agile
    too? I know there's been a lot of discussion of this in the agile
    community, but i haven't read any concrete accounts of trying to apply
    agile to large projects.

    Reason 3 is fair enough, but St Kent claims that software, in general, is
    not such a technology. I don't really know if he's right - if he isn't,
    the whole edifice of agile collapses.

    Reason 4 would certainly clobber agile. But i'm not sure it wouldn't
    clobber every other methodology too - they all depend on fast feedback in
    the final testing/QA phase anyway. Maybe there are projects when you can
    get fast feedback, but only for a limited time. Spacecraft software, for
    instance - you can afford to do a test shot at the end of the project, to
    see if everything works, but you can't afford to do them every month, to
    check the latest release. I'm not totally convinced this is a good reason;
    wouldn't you be pretty dependent on having some kind of pre-flight testing
    ability with waterfall, too? You wouldn't really wait until you lit the
    booster to do your QA, would you? Maybe aeroplane software is a better
    example; you have five years to develop the software for the Typhoon, but
    you won't be able to run it on a flying airframe until a year before the
    ship date, so you'd better be able to QA the living shit out of it in that
    window. Interesting. Does this say more about testing practices in other
    methodologies than it does about agile? Many years ago, i made close study
    of the official report into the loss of the first Ariane 5 test flight (in
    French, since it was for a French course - sacre bleu, le biais horizontal
    est devenu enorme! - although the existence of an english translation
    helped no end!):

    http://en.wikipedia.org/wiki/Ariane_5_Flight_501

    One of the most important lessons was that you need to do whole-system
    integration testing before the bird flies. You need to be able to
    completely and faithfully reproduce the experience of flight during
    development. Doesn't that mean you could do agile? At the end of every
    iteration, you 'deploy' to the simulator rig, and see if it works.

    So, er, yep. Reckon.

    tom

    --
    Let us learn to dream, gentlemen, and then perhaps we will learn the
    truth. -- Friedrich Kekule
     
    Tom Anderson, Jul 14, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vincent RICHOMME

    architecture to adopt

    Vincent RICHOMME, Dec 22, 2005, in forum: C++
    Replies:
    0
    Views:
    338
    Vincent RICHOMME
    Dec 22, 2005
  2. Replies:
    8
    Views:
    584
    Tonny Madsen
    May 15, 2007
  3. Erik Hollensbe

    X12::Parser - intent to adopt

    Erik Hollensbe, Dec 31, 2007, in forum: Perl
    Replies:
    2
    Views:
    2,441
    brian d foy
    Jan 1, 2008
  4. Ant Grinyer
    Replies:
    10
    Views:
    537
    Ian Collins
    Jul 11, 2008
  5. Chris Dew
    Replies:
    103
    Views:
    796
    Frasier Mruby
    Oct 11, 2008
Loading...

Share This Page