Before I go on to Part 3 and what we can do about drag let me deal with some of the discovered work unearthed by the comments on Part 2.
* Graph Quality
Mark Nau calls me out and says he doesn't see the curves. If we still worked in the same office I probably would ask him to help me do an actual rigorous statistical analysis of the data. The curves are there but they look shallow and I admit I was pretty disappointed after generating the graphs that they weren't more obvious.
As for not seeing much of a bump when we brought the new programmer on, I can explain that. He's only part-time - I'd estimate at him increasing our manpower by 25% or so. Factor in Fristrom's Law and it's less. He needed a ramp-up period. And his first task was huge but greatly underestimated. It could have shown on the graph as a simultaneous increase in scope and work, but instead it shows on the graph as an increase in neither.
But that goes to prove Mark's point - the graph isn't accurate. I'm not able to truly tease apart work and scope, and probably won't even bother on future projects. (Though it was nice to see that we actually have been working all these months, something that isn't obvious from the first graph.)
This graph is simply the delta between the two lines in the other graph - though they don't plot out to the same point in time; I made the graphs at different times. If the lines in the other graph were straight, this graph's lines would be straight as well, but this is not a straight line.
* Other curves?
Jake Simpson and Simon Cooke say they see different shaped curves on their projects - they both see sine waves or something approximating sine waves. It is possible on this project we're just looking at a portion of a big sine wave with a really large period. Which would be a good thing, because that means at some point we'll take off like a rocket and ship! I wouldn't be surprised, actually, if we do get a burst in the end, as we put our foot down about feature creep and the remaining bugs are all highly detailed spot fixes. If only there was some way to predict when that change would come.
Cooke sees the opposite from us, in a way: he sees little visual progress in the beginning, during ramp-up, later followed by a lot of visual progress. (Much like our programmer with his big, underestimated task.) He may be more waterfallish than we are - we tend to get something up-and-running *now* and refactor later. For us, the "up and running now" shows up as a lot of progress, and then the refactoring shows up as drag. (Maybe this agile stuff isn't all it's cracked up to be.)
* Feature Creep vs. Discovered Work?
How much scope increase was stuff we wanted vs. stuff we needed?
FWIW. Red & most of green are needed. Blue, yellow, and pink are wanted. Call it 60-40.
Though I hesitate to call that 40% literal 'feature creep' - most of our unnecessary fixes were not "add X" but "X would be better if you do Y". The feature was already there and we were tweaking it.
More interesting would be to see how this changes over time, but I didn't know until late in the project that you could set up Bugzilla to generate snapshot data that you can later graph. It would be fraught with inaccuracy anyway - at the beginning of the project, p3 meant must-fix and later came to mean nice-to-fix.
I'm guessing Busse's point: if you tighten the reins on feature creep, you can mitigate the effects of drag.
I'll try to get back on track next week, unless there are more interesting comments.