Comment I think it's rather (Score 1) 349
Without a decent proportion of "smart, talented, dedicated individuals" you're most likely going to fail whatever methodology you use.
Problem seems to be there's a large industry (and certified professionals embedded in middle-management) who have vested interests in pitching approaches, not solutions - and however good a programmer you are, you're not going to make the 'big-bucks' without at least flirting with management. This is a good thing, but tends to make people tie their colours to a particular mast.
IMHO most methodologies are good - some have particular strengths for particular tasks/organizations - but basically they're just common sense (formalized in a way that you can slap on a power-point and justify to the clueless guy with the money).
A theoretical worker works for a company that switched from water-fall to Theory of Constraints. He was naturally dubious, but after his intro decided that he quite liked the idea (he's certainly been guilty of coasting on a task that was coming along nicely and was going to finish by the planned end date).
Then the bad stuff happened - "We automatically lop 25% of the estimate as this is more efficient".. I can see some savings, but howabout we're more realistic and just see if this stops stuff over-running. Then we start planning (tasks, estimates, buffers, dependencies etc) and start piecing it together. End of the first day we've formalized that this project cannot be delivered ontime using TOC. So well somebody decides some dependencies can be removed. Oh, and then somebody else starts adding 'programmer tbc 1' to the plan etc.
Basically, projects fail for all manner of reasons and this is often associated to the methodology. Reality is that it's the same old humans pushing the same problems into the systems, which then just fail with slightly different nomenclature.
Problem seems to be there's a large industry (and certified professionals embedded in middle-management) who have vested interests in pitching approaches, not solutions - and however good a programmer you are, you're not going to make the 'big-bucks' without at least flirting with management. This is a good thing, but tends to make people tie their colours to a particular mast.
IMHO most methodologies are good - some have particular strengths for particular tasks/organizations - but basically they're just common sense (formalized in a way that you can slap on a power-point and justify to the clueless guy with the money).
A theoretical worker works for a company that switched from water-fall to Theory of Constraints. He was naturally dubious, but after his intro decided that he quite liked the idea (he's certainly been guilty of coasting on a task that was coming along nicely and was going to finish by the planned end date).
Then the bad stuff happened - "We automatically lop 25% of the estimate as this is more efficient".. I can see some savings, but howabout we're more realistic and just see if this stops stuff over-running. Then we start planning (tasks, estimates, buffers, dependencies etc) and start piecing it together. End of the first day we've formalized that this project cannot be delivered ontime using TOC. So well somebody decides some dependencies can be removed. Oh, and then somebody else starts adding 'programmer tbc 1' to the plan etc.
Basically, projects fail for all manner of reasons and this is often associated to the methodology. Reality is that it's the same old humans pushing the same problems into the systems, which then just fail with slightly different nomenclature.