My observations very much confirm his. Especially this point:

technology is a slave to personality. It doesn't matter how good the design, when there are unresolved problems in the organization.

Amen. And that's exactly what a lot of the latest project management styles try to fix.

I almost never dread technical challenges (especially in the cookie-cutter LOB apps I build in my day job), but I do fear organizational dysfunction.

Conway's Law Organizations which design systems will produce designs which are copies of the communication structures of those organizations.

Can you give some examples of "project management styles" that try to fix this?

Well, that's what I read into the Agile manifesto:

http://agilemanifesto.org/

Basically any modern project management style focused on people and needs instead of reams of documentation.

I've unfortunately never worked at a place that does this right, but I had the strong impression some really good companies do it right - I was blown away by Guidewire back when I was in the insurance business, for example, they really seemed to do project management right ( see https://www.guidewire.com/blog/best-practices , and stuff like this - https://www.guidewire.com/blog/best-practices/implementation... , Scott Hatland really impressed me as a guy that lived this kind of person-first approach ).

Since it's more of a people and organization thing than a formal "project management style" thing, I don't know if there's one "style" that does this above all - Agile, Scrum, Kanban, can all be twisted by people who don't understand the core concepts.

Unfortunately, in practice, Agile almost always devolves into a cargo cult: perform the ritual of the Standup at the appointed time, etc. and all will be well. Any actual personality management is papered over with appeals to authority.

I think teams that succeed do so despite using Agile (or any other management fad). A cohesive team that communicates well can succeed using Agile, sure, but the process is incidental; they would succeed using most any methodology. Survivorship bias leads people to believe that Agile (or whatever methodology-of-the-week is in play) is causative, when it is actually epiphenomenal.

Which brings us to the http://www.halfarsedagilemanifesto.org ?

Agile is hardly ever done properly. It doesn't fix the problem with having middle managers who form master/slave relationships, destroy team morale with bad decisions and credit pinching, or deal with the issue of having engineers who purposefully write bad software to "prove new technologies are not as good as old, tried and tested ones".

Given that set of criteria, I wonder how many good projects there actually are out "in the wold".

I would suspect that a small percentage of all projects undertaken are good, according to these criteria. Yet I can't help but think that, while these good projects might engender an enjoyable experience for all involved in its' development, that it wouldn't necessarily lead to a successful product in the marketplace.

What I'm getting at is I wonder good project, while nice to work on, leads to a good product. I am guessing most products probably didn't arise out of a good project, so from a business standpoint, how much is it worth to worry about attaining all these aspects.