Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Re: working according to the screen vs. improvisation

Expand Messages
  • Roy Morien
    Thank you Paul ... we re creeping up on it, I think. But, isn t one of the apparent benefits of agile development that development is actually more productive
    Message 1 of 70 , Sep 4, 2007
    • 0 Attachment
      Thank you Paul ... we're creeping up on it, I think.
       
      But, isn't one of the apparent benefits of agile development that development is actually more productive than the traditional approach.
       
      Therefore, all other things being equal, an agile approach should always be undertaken to take advantage of the productivity that is inherent in the approach.

      Surely this is applicable to a project where "the team is well established, the business domain is well known, the system is well known etc."? Of course, the question must be asked, is the business domain ever sufficiently well known, or the system sufficiently well known?
       
      I also would make the  point that where a system has been in use for a significant period, and enhancements and modifications are to be done, which are clearly identified requirements, then developing and delivering those enhancements would be done very effectively and efficiently, and with higher productivity, if they were done using an agile, iterative approach. It would just be that the development need not be so 'agile', but just iterative.
       
      And we should never discount the benefits of having your outcomes validated and verified at regular intervals, regardless of how much we think we know the requirements.

      And to what degree of certainty can we really ever 'know what we don't know'. That seems a bit like the statement that 'By now, we just know 10% of all knowledge'. How do we know what the 100% is?
       
      So 'knowing what we don't know' seems a bit of a contradiction in terms, to me.
       
      Thank you for the references, by the way. I will follow them up.
       
      Regards,
      Roy Morien


      To: scrumdevelopment@yahoogroups.com
      From: PaulOldfield1@...
      Date: Tue, 4 Sep 2007 11:00:33 +0000
      Subject: [scrumdevelopment] Re: working according to the screen vs. improvisation

      (responding to Roy)

      > Does anyone know the characteristics of projects that
      > are best undertaken in a planned, phased, rigorous
      > pre-definition style, and what are the characteristics
      > of a projects that are best done done in an agile,
      > iterative manner?
      > Or, to put it another way, in the terms of this email
      > discussion, What are "The attributes of a project that
      > determine how we ought to approach it"?

      Several writers have addressed this question directly,
      e.g. Boehm & Turner's book "Balancing Agility and
      Discipline" and Alistair Cockburn's 'Crystal' series.
      One level more abstract, there is Phil Armour's book
      "The Laws of Software Process" that is essential
      reading for any methodologist - if a bit too abstract
      for the real world :-)

      Using that latter source as inspiration I can give a short
      answer to your question:

      Software development process is at its strongest in
      helping us when we don't know what we don't know.
      Waterfall development process is at its strongest when
      we know what we don't know. Thus if Waterfall is ever
      the right process, it would be where, say, the team
      is well established, the business domain is well known,
      the system is well known, and the development team
      and customer have been working with each other for a
      long time. Upgrades to a well-established system may
      qualify.

      Assuming you mean what I would mean by "rigorous pre-
      definition", then all other projects would not
      qualify. We just don't know what we don't know, so
      we cannot pre-define a good solution, and doing it
      'rigorously' would waste even more effort.

      Paul Oldfield
      Capgemini




      Find out. SEEK Salary Centre: What are you really worth?
    • Roy Morien
      I understand that, Fay, but you are saying that the standards don t change ... but the code will change, by virtue of being developed ... and if it is being
      Message 70 of 70 , Sep 10, 2007
      • 0 Attachment
        I understand that, Fay, but you are saying that the standards don't change ... but the code will change, by virtue of being developed ... and if it is being developed, then it can be iteratively and frequently tested against the standards, and verified and validated regularly.
         
        And, yeah, I wish I had the million dollars to put up :)
         
        Regards,
        Roy Morien



        To: scrumdevelopment@yahoogroups.com
        From: istvan.fay@...
        Date: Mon, 10 Sep 2007 17:05:02 +0200
        Subject: [scrumdevelopment] Re: working according to the screen vs. improvisation

        Hi,

        Although I would love to get the one million dollars mentioned in the mail J. So, one area, where requirements do not change too much is programs that have to be compatible with standards. One such area, that I have seen was telecommunication, actually mobile phone systems. Sure, there were requirements modifications while developing the program, but a very important part was that a software has to fulfill standardized requirements, and standards do not change that fast. This is how products from different vendors can cooperate, so it is a key requirement. And the systems are big as hell!

        I suppose that situation can be enhanced to areas where you have to cooperate with an existing system.

        Best regards,

        Istvan Fay




        Watch Today! Roast a Rock Star: watch video interviews with hot music acts.
      Your message has been successfully submitted and would be delivered to recipients shortly.