1982RE: [scrumdevelopment] What's wrong with tracking estimates vs. actuals?
- Oct 6 9:53 PMDavid,
>I think there is a danger of "doing agile" for theI agree that "doing agile" is not an end in and of itself. Providing
>sake of it. The real goal is to make more money by
>delivering more value faster to the end of value
return on investment and return on expectation is the real goal.
We do this by producing working software that fulfills the needs of the
customer. I'm quite skeptical that we can do this by producing "metrics".
The only metric that counts is how many of the customer's requirements we
clear out of the backlog by delivering well-made, working software for a
Any other metric may or may not be a helpful guideline to help you
accomplish that primary goal, but some metrics are blatantly
counter-productive because they encourage the wrong behaviour.
I'm glad you agree that SLOC is not a good metric; crappy code can eat up
WAY more lines than good code. ;-)
>One of the big problems with agile successes is thatI suppose part of our disagreement comes from our different concerns. You
>they get reported in a relative manner
want to bring a scientific study to the successes of particular cases.
Though I'm skeptical that you can ever factor out all the variables that go
into a large project and isolate with absolute objectivity that one method
is better than another, I can understand why you want to do this.
However, I'm in the trenches, and the only reason I give a fig about the
Agile methodologies is that they offer approaches and techniques that solve
my real day to day challenges in building good, reliable, low cost
software. What Chrysler did, or some offshore bank, though perhaps of
academic interest will not sway me one way or another as to whether those
techniques will work for me. If they work for me, I use them, if they
don't, I won't.
>So I fail to accept that you can assert that adhoc,Well, since we are unlikely to find mutually satisfactory metrics for
>self-organizing processes can outperform lean
>processes which still include aspects such as planned
>versus actual dates.
determining performance, I don't think I would make that claim. ;-)
However, I do know that professionals who are too valuable to be fired are
smart enough to tell when they are being micro-managed or babied, and
neither of these brings out high morale, creativity and "can do" spirit.
Remember that people will focus their energies on whatever you measure to
evaluate them. If you measure their ability to estimate rather than their
ability to produce working software, you will encourage them to pace their
work to the plan, rather than doing the best they can always, to avoid
taking risks that might throw their estimations off, even if it would
improve the product.
I can't see how that will improve productivity. In fact, I wouldn't
believe it were so even if you showed me some metrics. ;-)
>When you can show me the metricsWhen the Buddha was asked "Why should I believe what your saying?", he
>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.
replied "Don't believe it. Try it for yourself ."
I can't improve on that. ;-)
- << Previous post in topic Next post in topic >>