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

Re: working according to the screen vs. improvisation

Expand Messages
  • markusrischar
    Roy, There are two main parts I am concerned on choice (1) uncertainty i.e. novelity in technology, complexity in technology and project and tacitness. (2)
    Message 1 of 70 , Sep 4, 2007
    • 0 Attachment

      Roy,

      There are two main parts I am concerned on choice (1) uncertainty i.e. novelity in technology, complexity in technology and project and tacitness. (2) capability, i.e. is you're organisation ready to be agile (e.g. can you manage self-organised teams, can you collaborate)?

      Of course, there are other factors to consider, e.g. safety, risk, as well as expected project effectiveness (i.e. quality, cost considerations, time).

      Balancing Agility and Discipline: A Guide for the Perplexed By Barry W. Boehm and Richard Turner is a good read with regards to this issue

      Markus


      --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
      >
      > There have been many opinions expressed over the years about what methodology is best for a particular type of project.
      >
      > I have a simple question.
      >
      > 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"?
      >
      > Regards,
      > Roy Morien
      >
      >
      > To: scrumdevelopment@...: PaulOldfield1@...: Tue, 4 Sep 2007 09:30:51 +0000Subject: [scrumdevelopment] Re: working according to the screen vs. improvisation
      >
      >
      >
      >
      > (responding to István Fáy)> My point is here, that may be it is not an exclusive> situation whether waterfall or scrum, but rather a> decision point for the project manager, who should> decide upon the attributes of the project and the> project team.The attributes of a project that determine how we oughtto approach it are discoveries rather than decisions.Having made those discoveries, then we can start making decisions on a knowledgeable basis rather than ad-hoc.The question arises; is the Project Manager the best person to make the decision? In reality, the answer isalways that for some small proportion of decisions, the Project Manager is the best person to make thatdecision.What we need to ask ourselves is; how do we get the decisions made by the people who are best placed to makethe decisions? Now, in the case where we have a really smart PM andreally stupid developers, "Command and Control" may bea good approach (I'm overstating the case deliberatelyto make a point). But then, starting from that point, the first improvement we should make is to get smarterdevelopers.To take you back to the screenplay analogy, to makethis analogy hold true, we would be starting the filmor play with only a roughed-out plot line for anythingbeyond the first act. Your actors would need, at some point, to be able to ad-lib if the story is to holdtogether. Then the ad-libs bring constraints andopportunities for later in the script. Paul OldfieldCapgemini
      >
      >
      >
      >
      >
      >
      > _________________________________________________________________
      > Win Dad the Footy Final with Cadbury Favourites!
      > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fbs%2Eserving%2Dsys%2Ecom%2FBurstingPipe%2FadServer%2Ebs%3Fcn%3Dtf%26c%3D20%26mc%3Dclick%26pli%3D243221%26pi%3D0%26ord%3D%25%25RANDOM%25%25&_t=765445318&_r=hotmail_email_tagline_Aug07_Cadburys&_m=EXT
      >

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