Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so my perspective on the subject may still be heretical.
That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossible to promise both a feature set and a due date.
To an approximation, that's what the whole sprinting thing is all about. It's breaking things down into bite-size pieces that are small and simple enough that you can hit milestones on deadlines with something approaching regularity. But on top of that you've got the overall development arc, and on that scale there are (or should be) no promises made about what's going to be happening on any sprint past the current one. The point of this is to buy the product team flexibility: Either the flexibility to adjust the requirements in response to new information that's discovered during the product lifecycle, or the flexibility to adjust the number of sprints that will be needed to achieve a given feature set in response to new information that's discovered during the product lifecycle.
In short, this is a feature of Agile not a bug. It's nothing more than being realistic about an immutable law of the universe: The more rigid you need to be about deadlines the less rigid you can be about requirements, and vice versa. Product teams have a professional responsibility to be honest about this fact. Customers and managers who aren't comfortable with it are free to restore their sense of certainty by building ample buffer space into the schedule.
Yes, you've definitely got the theory. In a well-run Agile shop, dates are derived from the backlog and the team's observed pace.
I'll add that Agile teams should also have something releasable every iteration (which ideally is every week). When that's true, dates are less of a problem. Instead of managers sweating engineers over when it will be done, managers in an Agile context spend their time arguing with other managers about the business question of whether to release something small and soon or something bigger and later.
In a well-run Agile context, anyhow. If you're not seeing those behaviors, but instead see the traditional drama, a high-pressure single convergence on a fixed date with fixed feature goals, then it's the sort of faux Agile this article is talking about.
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.
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.
> 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.
That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossible to promise both a feature set and a due date.
To an approximation, that's what the whole sprinting thing is all about. It's breaking things down into bite-size pieces that are small and simple enough that you can hit milestones on deadlines with something approaching regularity. But on top of that you've got the overall development arc, and on that scale there are (or should be) no promises made about what's going to be happening on any sprint past the current one. The point of this is to buy the product team flexibility: Either the flexibility to adjust the requirements in response to new information that's discovered during the product lifecycle, or the flexibility to adjust the number of sprints that will be needed to achieve a given feature set in response to new information that's discovered during the product lifecycle.
In short, this is a feature of Agile not a bug. It's nothing more than being realistic about an immutable law of the universe: The more rigid you need to be about deadlines the less rigid you can be about requirements, and vice versa. Product teams have a professional responsibility to be honest about this fact. Customers and managers who aren't comfortable with it are free to restore their sense of certainty by building ample buffer space into the schedule.