Re: Scrum Failure statistics
- --- In firstname.lastname@example.org, Chris Brooks <brookscl@c...>
> On Fri, 11 Feb 2005 11:53:13 -0600, Ken Delong <ken.delong@v...> wrote:80%, depending on whether you believe Gartner, or Standish, or Cutter,
> > The high rate of failure in software is well established: 50% -
> Make sure you define "failure".
> For the Standish "Chaos" report in 1994 , the following definitions
> were used:
> For purposes of the study, projects were classified into three
>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
- 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 completedI totally agree
> on-time and on-budget, with all features and functions as initially
> 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.
>  http://www1.standishgroup.com/sample_research/chaos_1994_1.php
> Chris Brooks