[vonmoltke]

If that is the case, then Agile just does not work for large, integrated engineering projects. You must make attempts at locking both feature sets and due dates because the progress of teams is interdependent and the flexibility each team has is highly variable. At some level of granularity there must be an established schedule that other teams can plan to. Its a basic part of systems engineering.

This is not to say these structures should be inflexible. There needs to be some flexibility in requirements and dates, and it is the responsibility of the program manager and systems engineer to make sure the project can bend without breaking. There must be limits on it, though, or the project will tear itself apart.

[bunderbunder]

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.

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.

[vonmoltke]

> 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.