Sounds like a typical offshoring disaster. I hope somebody somewhere up the command chain felt the consequences.

I've also had luck with waterfall-like development models, on projects from six months to about four years (although the four-year project did have three distinct iterations in order to manage risk). That was for a vehicle-mounted sensor to detect land mines, so there were obvious reliability concerns -- and we could meet them because waterfall let us budget time for detailed failure mode analyses, rather than trying to make that fulfill some user story within a single sprint.

Of course you would say that. You would still be wrong. What you call "organizational dysfunctions" -- but everyone else would call "a normal mix of people" -- can be handled more effectively under a waterfall-like process than under an Agile one. That doesn't make it less efficient.

If you want the same kinds and amount of work product (including detailed requirements, design documents, formal verification, etc.), Agile is likely to be less efficient because you start lots of developers writing code before anyone has a good grip on what the project should look like -- and they continue working furiously until the end. It looks nice because you have something to show and everybody is busy, but the something doesn't fit the need and you're burning through your budget.

Telling people what is blocking your progress *is* pointing fingers, friend.

Waterfall does not need that many long meetings. Instead of five 15-minute scrums in a week, I've typically had one 30- to 40-minute status meeting in a week.

Waterfall does not require the users to know in advance exactly what they want. Why do agilistas spout that nonsense (beyond it being part of the creed)?

If your project leads -- managers, systems engineers, whoever deals with the customer most -- do not know how to deal with vague requirements, irrational schedules, or requirements changes, your project is going to fail regardless of methodology. Agile exacerbates and encourages those problems.

Successful waterfall does not have the problem you claim with requirements elicitation because that is part of what a good system engineer does. I guess agilistas have never worked with good systems engineers. Unless the customer is a professional software developer, it is natural that he or she can't explain their business requirements in the kind of detail that is needed to guide software development and testing. The development team can still develop "use cases" (IMO a more cumbersome, but clearer, term than "stories" -- but basically the same thing) and refine them enough for developers to use.

Waterfall is fragile to change only to the extent that the project is mismanaged -- yet when agile is mismanaged, it fails more spectacularly than waterfall. Agile is designed to make a more convincing appearance of progress, but it is also designed to throw more code away.

Put as much lipstick on that pig as you want, but it's still going to squeal.

A functional waterfall-style team needs two people to be good at their jobs: A manager (to keep everyone pointed in the same direction) and a system engineer (to make sure that direction is a good one). By your argument, a functional agile-style team needs almost everyone to be good. Most teams aren't like that, and the ones that are will do pretty well with any methodology.

Where did you go during that six months, and did the team's manager get fired for not doing his or her job?

If developers are not allowed to add their own bugs or issues, then either your team is too big for agile or the project is too small for your team. Instead of prohibiting that, somebody needs to oversee all the bugs and issues that get added, and part of their job should be to provide feedback when anybody submits an issue report that is not well-aligned with the customer's or user's interests.

How do you square that advice with the agile advocacy of incremental development starting with a minimal prototype? Anybody who thinks about it objectively realizes that you don't want a mock-up to be backed by anything like your final code, but Agile strongly calls for developing a minimal app that can finish user stories -- and then solving more stories by extending that code. That conflicts with the first pass being a mock-up that you expect to extensively rework.

What's actually documented is that big software projects have a high probability of failure. The level of detail in their requirements is, like the failure rate, a consequence of size.

Agile seems mostly like it is meant to let developers write more prototypes, with the expectation of throwing them away, in the name of "responding to change" -- particularly when, as often as not, the change is due to defects in the development process rather than any underlying technical or business reason. Instead of planning, there's a frivolous focus on making things that look good or check some box but don't necessarily have a solid architecture.

You are basically just saying that agile is more *fr*agile than waterfall -- given two teams of equal "discipline" and skill, you're likely to have something closer to the original intention with waterfall than with agile, because (in your words) agile requires more discipline to work well. Also, you're spouting nonsense when you say that the point of daily meetings is to free managers from micro-managing; if they wanted to stop micro-managing, they would not have a meeting each day where the explicit purpose is to point fingers.

Waterfall doesn't need a long QA/QC cycle if you put thought into design validation and verification beforehand, and spend some time developing tests in parallel with developing code. Putting off test planning and preparation will hose you whether you use waterfall or agile or whatever else.

More to the point, who outside Apple develops embedded software for an Apple platform?

I apparently know better than you what a typo is.

I regret thinking you had any intention of arguing in good faith, and shall not make that mistake again.