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

RE: [scrumdevelopment] Agile/Scrum disadvantages

Expand Messages
  • Mitch Lacey
    Hi Steve. No, I do not consider this impolite - it s a good discussion and I appreciate you sharing your point of view. You summarize it the best in my eyes.
    Message 1 of 135 , Dec 31, 2006
    • 0 Attachment

      Hi Steve.


      No, I do not consider this impolite – it’s a good discussion and I appreciate you sharing your point of view.


      You summarize it the best in my eyes.

      “The objective should be to reduce the cost of project failures, not eliminate them or even figure out who to blame for them.”


      I could not agree more with you on this – I am not advocating elimination of all failure.  What I would like to see is accountability.  People are too often accountable when there is success, but when there is failure, the tail goes between the legs and everything else but the people that made the situation what it is take the hit.  I guess the phrase “grow some balls” comes to mind. J


      The other topics could probably be debated for days, but we’d need food and beer for that.




      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Steven Gordon
      Sent: Sunday, December 31, 2006 2:55 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Agile/Scrum disadvantages



      I hope my continuation of the argument is not considered impolite:

      Suppose the company is acquired by another company who already has a competing product and therefore kills the project.  Whose failure is that?

      Suppose the market suddenly changes so as to make the product being developed unprofitable.  Whose failure is that?

      Suppose there never really was a profitable market for the product, but that fact could only be discovered by market testing the version produced after 2 months of development.  Whose failure is that?

      Suppose that building the product within a reasonable budget with the current state of technology is not feasible, but this fact could only be verified/discovered by trying for 2 months.  Whose failure is that?


      Even in the type of example you cite, management might conceivably be making a good business decision when it decides that unblocking one particular project would threaten too many other projects or even normal business operations.  Eventhough management is "failing" to support a project and the decision looks irrationally political from the point of view of the people on that project, if the decision making is rationally based on the bigger pricture, then perhaps there is no failure occurring at all on the part of any person or process.  I suspect this is true in less than half of such cases, but it does happen.

      If no projects are failing at a company, one of the two conditions below is most likely:
      - The company is not assuming enough risk to be competitive in the long run, or
      - All failures are being covered up by the managers whose careers would be threatened by admitting the failure (in these cases, millions of dollars are wasted continuing the project to completion even after failure was obvious to everyone involved).

      The objective should be to reduce the cost of project failures, not eliminate them or even figure out who to blame for them.


      On 12/31/06, Mitch Lacey <mitch.lacey@...> wrote:

      Hi Steve.


      I agree and disagree, politely.  J   My take is this:

      Say everyone on a project has the best intent.  Say an issue arises, and I try to do the right thing by overcommunicating the issue to help unblock the team / organization.  Say I get slapped and politics are cited, like "that's not the way we do things here" or "your job is to test, nothing more".


      I guess in scenarios like these, even though the team (or just me) has the best intent, it is impossible for everyone (and I mean every possible touch point) to have the same intent.  There are always detractors. 


      As a result, the people fail – the process only highlights or masks that failure – and as a result, since most people don't like to take accountability for failure (only success), the process has failed.


      I've seen this happen over and over and over again at my last company (search the DL for my previous posts and you'll figure out who the company is) – so it's my perception and experience that processes do not fail, people do.


      Have a good new year! 




      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Steven Gordon
      Sent: Thursday, December 28, 2006 8:43 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Agile/Scrum disadvantages


      On 12/28/06, Mitch Lacey <mitch.lacey@...

      > wrote:
      > In reading all the posts to this thread, twice, I was surprised that no one pointed this out.
      > There is an assertion made by the original poster and then again below
      with regards to "the agile process failing"
      > Processes do not fail, the people working in them do.

      Even this is not totally true. Sometimes a project fails despite the
      very best intentions and efforts of everyone involved.

      One thing I like about the agile approach is that if the seeds of
      failure are there, they tend to be discovered and confronted much
      earlier than in traditional command-and-control approaches where it
      seems to be in nobody's interest to point out that "the emperor is
      wearing no clothes".

      The earlier discovery of the potential seeds of failure sometimes
      means we can fix the problems or successfully campaign to get the
      problems fixed if they are outside our sphere of influence, but in
      some cases it just means the failure is quicker, less painful, and
      less expensive that if we had not confronted the issues. Is this
      failure or success?

      > Now there are advantages and disadvantages to everything, but like Ron
      pointed out, would traditional teams of the same inexperience do better, or even worse?

      I have experiences some large organizations in which an early failure
      or reduced scope was considered a worse result than a project
      completed to spec whose financial return was less than the cost of
      producing it, finally getting it to work, deploying it and maintaining
      it. In such bizarro worlds ruled by politics and accounting tricks,
      it is quite possible that traditional teams would seem to fare better.



    • Dave Nicolette
      Ewww! Slimy hands! Dave ... http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of-agile-software.html
      Message 135 of 135 , Sep 5, 2007
      • 0 Attachment
        Ewww! Slimy hands!


        --- In scrumdevelopment@yahoogroups.com, "Henrik Kniberg" <h@...> wrote:
        > >
        > Interesting list of "disadvantages" :o)
        > - Active user involvement and close collaboration
        > - Requirements emerge and evolve
        > - Agile requirements are barely sufficient
        > - Testing is integrated throughout the lifecycle
        > - Frequent delivery, and the need to signoff each feature as Done.
        > Challenges? Yes, certainly.
        > Disadvantages? Well....
        > Calling "Requirements emerge and evolve" a disadvantage sort of
        > implies that "You must specify everything upfront" would be an
        > advantage.
        > Sort of like saying:
        > "The disadvantage of having the lethal tumor removed is that the
        > surgeon has to cut me"
        > or "The disadvantage of pulling the leach off my body is that my hands
        > will get slimy".
        > :o)
        > I do get your point though. Many people of a waterfallish mindset will
        > initially *perceive* these as disadvantages, while the real
        > disadvantage is the fact that the transition may be difficult and
        > costly, which we must take into account.
        > Great site BTW.
        > /Henrik
        > --
        > Henrik Kniberg
        > http://www.crisp.se
        > +46 (0)70 492 5284
        > On 9/4/07, kswaters1 <allaboutagile@...> wrote:
        > >
        > >
        > >
        > >
        > >
        > >
        > > My thoughts on question #1 - what are the disadvantages of agile
        > > software development?
        > >
        > > http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of-
        > > agile-software.html
        > >
        > > Kelly Waters
        > > http://www.allaboutagile.com
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "Mike Bria" <bria526xp@>
        > > wrote:
        > > >
        > > > For clarity, I'd like to point out that I feel Deepinder has asked
        > > two
        > > > largely distinct questions:
        > > > 1/ What are the /disadvantages/ of using an agile methodology?
        > > > 2/ What are the /potential pitfalls/ when using an agile
        > > methodology?
        > > >
        > > > Some of the responses so far have addressed question #2.
        > > > Some of the responses have addressed an unasked (but good)
        > > question: "What
        > > > might adopting Agile expose about your organization?"
        > > > I don't think #1 (the subject of the thread) hasn't gotten much
        > > airtime
        > > > though.
        > > >
        > > > Does anyone have any thoughts on #1?
        > > > --MB
        > > >
        > > > On 12/28/06, PaulOldfield1@ <PaulOldfield1@> wrote:
        > > > >
        > > > > (responding to Deepinder)
        > > > >
        > > > > > All of you have experience in Agile and Scrum, I would like to
        > > know what
        > > > > > are the disadvantages of using Agile process where all it can
        > > fail as
        > > > > > compared with other traditional processes?
        > > > >
        > > > > Going by reports I've heard rather than any in-depth study; I
        > > seem
        > > > > to hear that while a relatively inexperienced team can do a good
        > > > > job at detecting problems, they are often not experienced enough
        > > > > to change things in a way that makes things better.
        > > > >
        > > > > One way to help counter this is to 'go by the book' for at least
        > > 6
        > > > > months and start to build up experience of what 'going by the
        > > book'
        > > > > can do for you (and hopefully, why it does). Another way is to
        > > get
        > > > > some good, experienced help to make any necessary tweaks
        > > > > and explain why they are good changes to make.
        > > > >
        > > > > Paul Oldfield
        > > > >
        > > > >
        > > > >
        > > >
        > >
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.