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.

Facebook was a typo. Please excuse my brain for substituting one social networking site for another one. Do you get so easily butthurt because you're an oversensitive moron, or because you're a troll?

I know perfectly well why it's a stupid thing to do, regardless of whether one has a security clearance or even any significant access to trade secrets, export-controlled materials, or anything similar. I can't convince strangers about that, though, and I haven't been on the receiving end of such spam, so I don't have a solution for the general problem. I do think it is spectacularly stupid to jump, as you did, from "LinkedIn has an entirely optional way for you to give them control of your email" to "DOD employees should not be allowed to use FaceBook, period". My way of fighting that particular stupidity is to call you on it.

Are you getting those invitations from people with security clearances? If so, try letting their security officers know -- security@example.org, or whatever domain name they used. They will almost certainly get a dressing down, will probably get written up, and everyone else at the site or company will get a sternly worded reminder (in addition to their annual training) never to share their passwords with anyone, for any reason.

You complain loudly that people with clearances shouldn't do that, but so far you have not even asserted that they have done that -- only that some people on the Internet do -- much less provided so much as an anecdote to convince anyone that they gave their password to LinkedIn. That's most of why I called you and your argument stupid. The other part is that you jumped straight from "LinkedIn lets you do something stupid" to "I simply cannot fathom any DOD employees being allowed to use LinkedIn, period", and that's missing a whole chain of implications to support the conclusion.

DC has a moderate number of non-cleared (and even mostly unrelated to government) jobs in IT and engineering. They pay much closer to the national average. A while back, a recruiter I talked to seemed very surprised that a software development manager with 10 years of progressively advancing experience and a secret (not TS or poly) clearance could make $140k/year. Salary-survey web sites seem to say IT and engineering fields average $100k-$120k/year, which seems low to me; maybe I haven't looked at all the non-government-related jobs enough.