> Right. . . hence the sentence on the end about needing to use buffer space to handle the things that Agile never promised it could handle in the first place.
A schedule can only have so much pad. My assertion is that Agile is useless to these projects because it can't handle these things.
> I'd point out that the same problem exists for every other software development methodology I've ever tried. The difference is that when they do slip deadlines, it tends to be a whole lot more surprising (and therefore damaging to the schedules of other teams) because their feedback mechanisms tend to result in poorer-quality progress tracking.
Every project management methodology has these problems, because at some level these problems are political. No methodology is going to overcome that, though some are better than others at dealing with it. The poster I first replied to said, Agile works fine for teams that embrace it. I'm saying such is not the case if you are working in an integrated or "team of teams" environment or if you have an unreasonable customer. Those may not be very common in the pure commercial software world, but they are in the rest of the world that software is trying to eat.
