In XP they claim that XP practices make the cost of change curve shallow and
that's why XP works.
However, Scrum doesn't (necessarily) do most of the XP practices. But it
still works.
How come?
I have 2 complimentary theories:
1)Boehm's original cost of change study showed that the cost of change ratio
(between fixing in production vs. requirements stage) for SMALL projects is
5:1, not 100:1. So if we're working on small projects we have a shallow
curve. But if we are working on big projects and we break the project into
cleanly decoupled teams we can largely isolate the effects of change and
also have a shallow curve.
2) The original study was done in the late 70's when people were doing
(mostly) waterfall projects so the survey shows the cost of change curve for
waterfall projects. There were no agile/iterative/incremental/whatever
projects so the study can say nothing about
agile/iterative/incremental/whateverprojects.
[If I do a survey of adult males and conclude that the average shoe size is
X, I wouldn't assume the average shoe size of female children is also X]
Boehm and Turner (in Balancing Discipline and Agility) say that recent
studies confirm the original 100:1 ratio. But, these studies make no
distinction between waterfall or agile/iterative/incremental/whatever and,
given that if thre were any agile/iterative/incremental/whatever projects in
the study it is likely to be a small proportion of the total, then these
studies also tell us nothing about agile/iterative/incremental/whatever
projects.
So, the cost of change curve is based on waterfall projects and, in a vicous
circle, was used to justify waterfall projects.
Could it be possible that working agile/iterative/incremental/whatever,
using good modern development tools, techniques and practices, with good
people, in nicely decoupled teams give us a low cost of change curve?
In XP they claim that XP practices make the cost of change curve shallow and that's why XP works. However, Scrum doesn't (necessarily) do most of the XP...
A third theory (when I read the next page of Boehm and Turner): 3. In the more recent studies when the changes were broken down further it turned out 20% of...
If we can identify those 20%, perhaps we can mitigate them better by handling them as late as possible instead of just trying to guess them better up front. We...
... XP lowers cost of change via... - test driven development - refactoring - continuous integration - frequent releases - non-heinous organization guidelines ...
Phlip
phlipcpp@...
Feb 15, 2004 2:11 am
... These are the things that XP teams do, with 2/3 or so of them perhaps a bit boiled down. ... A bit of a sparse definition, somewhat like saying that "Celle...
(responding to Clarke) I think you (Clarke) are already aware of my thoughts on this topic, but to get a wider debate, I'll air them here to see whether other...
... This seems like a survey of thoughts with no particular trend toward a conclusion. What am I missing? Ron Jeffries www.XProgramming.com It is not the...
... Two different topics: - reduce the cost of change - reduce the odds of change Get the first by writing code by changing it. Get the second by collating...
Phlip
phlipcpp@...
Feb 15, 2004 2:02 pm
(responding to Ron) ... The conclusion is that the Beck and Boehm cost of change curves need not be contradictory, it may be that they apply to change during...
... One major source of reducing the cost of charge is deferring infrastructure decisions as long as possible. Another is strong interface/implementation...
... In my experience with embedded software work, using XP, I found that these methods did sufficiently drive down the cost of change. Even with hardware in...
... May we interpret that hardware reduces the odds of change, and partnering with another company increases the odds? You seem to imply the cost of change was...
Phlip
phlipcpp@...
Feb 16, 2004 2:52 am
... I believe that both circumstances tend to drive up the cost of change. I wasn't referring to the odds of change, but now that I think about it I tend to...
I'd say the most important thing ... There are two elements in this "cost of change" discussion. Boehm's original article, the exponential curve Kent referred...
... TDD reduces the first. Small iterations with features sorted in Business Value Order reduce the second. So, with only the second the cost of rework can...
Phlip
phlipcpp@...
Feb 16, 2004 6:03 am
aac> There are two elements in this "cost of change" discussion. aac> Boehm's original article, the exponential curve Kent referred to, was aac> about...
I believe Alistair is declaring the 2 topics are the cost of repairing mistakes and the cost of handling ordinary changes. Alistair declares that the cost of...
... Yes, Alistair concludes that 20 cents to two dollars is just as exponential as Boehm's 1, 10, 100. And of course it is, if you're a mathematician. On the...
... RJ> Yes. Another issue that impacts processes like Scrum and XP is that, RJ> whatever the cost may be, it is visible, because we focus on shipping RJ>...
aac> Scenario #1: aac> ------------ aac> Customer: Okay, now whenever we deposit into an account and the new aac> balance is over five thousand dollars we have...
(responding to Alistair) ... I think there are a whole range of types of 'mistake'. Recovering from a mistake in capturing a requirement can be very similar to...
(responding to Ron) ... You need to use the right curve. This is a new requirement, so you're starting the exponential curve at the start of the week you took...
I've seen unagile processes where 6-month feedback latencies were still faster than the developers could make changes. Traveling 70 MPH at night, I sure hope...
... Strike "turning radius". One shouldn't use all of it at 70 MPH. Orthogonal iterations would ensue. A process becomes agile when the rate that feedback ...
Phlip
phlipcpp@...
Feb 16, 2004 6:04 pm
I rather liked "turning radius". If your headlights cannot illuminate that far out you either have to: a) get out the car and check whats ahead then drive...
Offline 
Send Email