Between waterfall, agile and hybrid, what is the best approach to project management?

Kudos to Sergio for stating up-front that "Agile is not a method" and going right to the real questions to look at when defining a software-development approach for a particular project. I have seen astonishing abuses of "Agile" as a buzzword and, worse, an excuse to take shortcuts (especially with respect to documentation and testing).

What do you all think of this notion: Except for the extremes at each end--lean, fine-grained iterative development à la Scrum, and Grand Vision waterfall--the best approach to any project is some hybrid. And, as Sergio noted, the Agile philosophy can be applied to any approach.

Is your product highly user/UI-oriented? Can it be defined in terms of distinct, relatively simple use-cases? Does it call for a data model that can be partitioned into relatively independent groups of entities? Then consider JAD, short sprints, QA based on user testing, and minimal documentation.

Are you developing a large system with lots of functional and data interdependencies? Is the user interface more of a front-end to state- or transaction-oriented business logic? Is the system as a whole mission-critical? Does it demand extremely high reliability? Then you're looking at larger functional modules, longer iterations (months, not weeks), greater need for documentation (especially design and technical), and rigorous formal testing at all levels.

I don't have the degree and diversity of experience that many of you do, so I welcome feedback, criticism, corrections...as long as it's civil and constructive.

Kudos to Sergio for stating up-front that "Agile is not a method" and going right to the real questions to look at when defining a software-development approach for a particular project. I have seen astonishing abuses of "Agile" as a buzzword and, worse, an excuse to take shortcuts (especially with respect to documentation and testing).

What do you all think of this notion: Except for the extremes at each end--lean, fine-grained iterative development à la Scrum, and Grand Vision waterfall--the best approach to any project is some hybrid. And, as Sergio noted, the Agile philosophy can be applied to any approach.

Is your product highly user/UI-oriented? Can it be defined in terms of distinct, relatively simple use-cases? Does it call for a data model that can be partitioned into relatively independent groups of entities? Then consider JAD, short sprints, QA based on user testing, and minimal documentation.

Are you developing a large system with lots of functional and data interdependencies? Is the user interface more of a front-end to state- or transaction-oriented business logic? Is the system as a whole mission-critical? Does it demand extremely high reliability? Then you're looking at larger functional modules, longer iterations (months, not weeks), greater need for documentation (especially design and technical), and rigorous formal testing at all levels.

I don't have the degree and diversity of experience that many of you do, so I welcome feedback, criticism, corrections...as long as it's civil and constructive.

I feel we get so bound up in picking the right 'method' that we lose sight of what we are trying to do. It doesn't matter what method you use, if you can't deliver a quality outcome. It all boils down to are you 'doing the right things'. You can do everything right according to the methodology, but still not be doing the right things to be successful.