1981RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?
- Oct 6, 2003Marc,
I think there is a danger of "doing agile" for the
sake of it. The real goal is to make more money by
delivering more value faster to the end of value
chain. If agilists lose sight of this then agile will
be a fad rather than a genuine trend.
I would contest your observation that making the best
ROI or the most money is always best done using the
very pure agile techniques you describe.
For example, in the Boehm and Turner book they
describe a 3 year long XP project which using more
than 30 developers in a 50 person team produced around
500,000 SLOC. Compare this to the CLS project at UOB
in Singapore (the original FDD project) which was
performed using the fine-grained planned versus actual
which with slightly less people (47) but with only 23
developers produced 1,500,000 SLOC in only 18 months.
If SLOC is a reliable metric (and I don't believe it
is but given a lack of a function point assessment of
both projects it is all we have) then the first FDD
project seems to be up to 6 times more effective than
the textbook XP project reported by Boehm and Turner.
Not only was the CLS project a huge success but after
it was rolled live - the bank (UOB) was able to take
over its nearest competitor. This was achieved through
improved competitiveness and the lending system
delivered by the CLS project played a key part in
providing that competitiveness.
One of the big problems with agile successes is that
they get reported in a relative manner e.g. we
implemented (pick a method you like e.g. Scrum) and we
produced a four fold improvement. There are lots of
such anecdotes. Ken even includes one in the Scrum
book. However, none of these results are reported as
absolute figures in a normalized manner. The success
has a lot to do with the starting position. It's
always easy to improve a very poor organization.
So I fail to accept that you can assert that adhoc,
self-organizing processes can outperform lean
processes which still include aspects such as planned
versus actual dates. When you can show me the metrics
from real projects reported in a normalized fashion,
from projects performed in large businesses with large
value-added or revenue generation potential then I
might start to believe.
David J. Anderson
author of "Agile Management for Software Engineering"
--- Marc Hamann <marc@...> wrote:
My claim is not that your approach doesn't work; there
systems that have been built using BDUF or even ad hoc
I'm sure that many of these conform to various sorts
of acceptable metrics.
However, such practices are not Agile in general or
particular. Moreover, they work against the goals and
values that Agile
and Scrum promote, which is counter-productive if you
are trying to combine
them with Agile practices.
My implication that the team should be fired was
provocative, but "that
won't work here because of our culture/our
programmers/our boss" is the
most common objection I hear to using Agile
techniques. This seems
counter-intuitive to me, since I believe that the
great virtue of Agile
techniques is that they can be used even in adverse
You don't have to change the culture to start using
the techniques; just do
your best to implement the practices, and avoid any
practices which work
against the goals and values you are trying to
It's not magic, it's not easy, but if you don't at
least try the best you
can, you can't claim to be doing Scrum or Agile.
David J Anderson
Author of "Agile Management for Software Engineering"
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
- << Previous post in topic Next post in topic >>