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

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

Expand Messages
  • an.narasimhan
    An interesting chain of points. I am new to this email group and have been studying the mails in this group which are very useful and have a lot of practical
    Message 1 of 70 , Sep 5, 2007
      An interesting chain of points. I am new to this email group and have been studying the mails
      in this group which are very useful and have a lot of practical value. Having been involved with
      several companies in Bangalore in their transition to Scrum, I have a few points to add:

      1. Most companies where I have coached on Scrum used to claim that they are already
      agile. However, when I actually started to coach, I found that they have implemented
      one or two agile practices (that too partially) and claim they are agile. One such company was
      also complaining about reduction in productivity.

      2. many companies are new to agile and still in the stabilisation phase and there is a
      possibility that they are seeing some reduction in productivity compared to earlier since
      they have been using waterfall for decades.

      3. However, the companies where scrum is reasonably stable have definitely seen an
      improvement in productivity. Companies have also learnt to look at gains in a wholistic
      fashion such as:
          -Scrum delivers most valued features
          -Quality of what is delivered is definitely better due to the amount of integration and testing
           that the product undergoes.
          -Employee participation and learning of cross-skills has tremendous advantages
          -Employee morale is much better due to better work-life balance
          and so on...

      When Scrum is implemented properly, they have all experienced overall gains.
      Productivity gains should also be viewed with better throughput and cannot be seen in isolation.
      Scrum definitely helps in better throughput and when stabilised and properly practiced, better productivity in
      my experience.


      Roy Morien wrote:

      An interesting point, that Waterfall is more productive than Agile. I would like to see the evidence of that. In fact, one research paper that I have indicates (from a study of over 43,000 projects) that productivity was 20% greater than when using an iterative, incremental development approach, compared to using the Waterfall Approach. This conclusion was based on comparative Function Point Analysis and delivery times.
      That paper is Solon R., 2002, Benchmarking the ROI for software Process Improvement, The DOD Software Tech News, Novemberember 2002, USA, DoD.

      My personal experience has been that using a software prototyping approach, with appropriate development tools, can actually achieve a 50% saving in development cost. This was achieved through the use of application generators, report writers etc., which I am sure could not have been beneficially used in a Waterfall Approach. This figure of 50% however must be seen as anecdotal, and not supported by any extensive research.
      From the agile discussions and literature, one significant 'psychological' factor has been cited that contributes substantially to productivity. That is, when a deadline approaches, develoeprs are more focused on achieving the required outcomes, and more is achieved in the last period leading up to the deadline. When there is a deadline every 2 weeks, then that implies a continual focus by developers on achieving their intended outcomes. This is not to imply that a highly stressed, driven team is the way to go, of course. Focus on impending deadlines does not mean that at all.
      The fact of project delivereables being validated and verified on a regular basis does not necessarilly imply loss of productivity. In fact, overall it may well add to productivity by the reduction or even eradication of rework. Where there may be an apeparance of loss of productivity is wghere such validation and verification action throws up new requirements which must be added to the project workload. But this is seen as a beneficial outcome, from an agile development point of view, because of the presumption that those requirements are newly discovered business value, and the ultimate system will be providing greater business value, and be closer to contemporary requirements at the ultimate point of completion of the project.


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

      (responding to Roy)

      > But, isn't one of the apparent benefits of agile
      > development that development is actually more
      > productive than the traditional approach.

      At least a couple of the Agile thought leaders have
      expressed the view that, where it works, Waterfall
      is more productive than Agile. I seem to recall
      a figure of c. 10% overhead in Agile being suggested.
      Of course, the "Where it works" is the killer clause.
      That improvement only applies where we get everything
      right first time.

      > ... Of course, the question must be asked, is the
      > business domain ever sufficiently well known, or
      > the system sufficiently well known?

      It happens. Just not very often.

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

      Agreed, we could still choose to use an agile approach
      and take the (presumptive) 10% hit in productivity.
      Let's call it an 'insurance premium' in case there really
      is something pertinent that we don't know we don't know.

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

      That's what insurance is for, true. Yet this activity of
      validating and verifying at regular intervals is part of
      that overhead.

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

      Well, indeed. There's the rub. Yet I am prepared to admit
      of the possibility that such circumstances can occur.

      On a topical note, I pay flood insurance on my house, as part
      of a standard package. Now if my house ever gets flooded, the
      whole of Western Europe is in dire trouble...

      Paul Oldfield

      Find what you want @ www.eBay.com. au. Make shopping exciting.

    • 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
        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 :)
        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


        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.