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

Re: Scrum Failure statistics

Expand Messages
  • Deb
    ... 80%, depending on whether you believe Gartner, or Standish, or Cutter, etc.... ... How does Scrum fit in with these categories? It s not simple. At our
    Message 1 of 7 , Feb 14, 2005
      --- In scrumdevelopment@yahoogroups.com, Chris Brooks <brookscl@c...>
      > On Fri, 11 Feb 2005 11:53:13 -0600, Ken Delong <ken.delong@v...> wrote:
      > > The high rate of failure in software is well established: 50% -
      80%, depending on whether you believe Gartner, or Standish, or Cutter,
      > Make sure you define "failure".
      > For the Standish "Chaos" report in 1994 [1], the following definitions
      > were used:
      > For purposes of the study, projects were classified into three
      resolution types:
      > ----

      How does Scrum fit in with these categories? It's not simple. At our
      best, we claim to:

      - deliver incrementally, starting well in advance of the final
      delivery date;
      - discover and deliver what the customer *needs*, rather than the
      legalistic and simplistic "as initially specified";
      - if we're doing our job right, the project may well be cancelled
      while there are still some items in the backlog - those low-return
      items that don't warrant the demonstrated of development. Some of
      these may even be from the sacred "as initially specified" list!

      Comparing this with the list below feels like apples-and-oranges to
      me. Below, measurements are in terms of "number of features" rather
      than value of features to the customer, and in terms of "contracted
      requirements" rather than "real requirements". There is no room in
      these categories for one big strength of Scrum (and Agile in general):
      when business constraints change, we can turn on a dime and deliver
      "later" features earlier, to gain business advantage. Which is more
      important - the "plan" or the customer's success? How do we measure that?

      > Resolution Type 1, or project success: The project is completed
      > on-time and on-budget, with all features and functions as initially
      > specified.
      > Resolution Type 2, or project challenged: The project is completed
      > and operational but over-budget, over the time estimate, and offers
      > fewer features and functions than originally specified.
      > Resolution Type 3, or project impaired: The project is canceled at
      > some point during the development cycle.
      > Overall, the success rate was only 16.2%, while challenged projects
      > accounted for 52.7%, and impaired (canceled) for 31.1%.
      > ----
      > Their definitions are somewhat at odds with an Agile approach like
      > Scrum where you are much more likely to have not defined the entire
      > scope of the project up front. Some would argue that most Scrum
      > projects, even those deemed "successful", would fall into the
      > Resolution Type 2 category.
      > I'm not saying I agree with the Standish methodology. I'm just
      > asserting that there are many different definitions out there for what
      > success and failure are.

      I totally agree
      > [1] http://www1.standishgroup.com/sample_research/chaos_1994_1.php
      > --
      > Chris Brooks
      > http://www.chrisbrooks.org
    Your message has been successfully submitted and would be delivered to recipients shortly.