> So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront
Fundamental to agile is to have clear requirements, the time is not fixed.
With reference to the quality (scope), time, and cost triangle, each of the major methods picks one point to emphasise, another to fix (not allow to change), and another it manages the change of.
Agile wants speed so time is its emphasis, it does that by fixing cost (over a release period) and allowing changing scope, and it does that by limiting the features that go into a release. That doesn't mean that the features required should be unclear. I will deliver these 5 features out of 30 in the next 2 weeks at X dollars. If one of the features isn't ready, we'll drop it. No, I'm not doing features 6,7,8 till later. Yes, you can change you mind about what you want for later releases.
Lean emphasises quality and fixes cost while allowing time to change. You can get your burger for X dollars but you're 5th in the queue, you'll have to wait.
Traditional is about predictable cost, it (tries to) fixes time and allows change in quality to remain on budget. If everything goes to plan you should come in on time and on budget but maybe with less features or worse features than you wanted.
Of course, we know that traditional done badly produces over-budget, over-time projects that don't do what they were supposed to. It seems that agile methods are being used as cover for bad management because, as this entire thread is evidence of, there is widespread misunderstanding of the basics of project management. If you're going into an "agile" project and the requirements that you have are unclear then you need to kick up a fuss and hold the PM and the product owner to account. They should certainly be clear by the beginning of each sprint.
Fundamental to agile is to have clear requirements, the time is not fixed.
With reference to the quality (scope), time, and cost triangle, each of the major methods picks one point to emphasise, another to fix (not allow to change), and another it manages the change of.
Agile wants speed so time is its emphasis, it does that by fixing cost (over a release period) and allowing changing scope, and it does that by limiting the features that go into a release. That doesn't mean that the features required should be unclear. I will deliver these 5 features out of 30 in the next 2 weeks at X dollars. If one of the features isn't ready, we'll drop it. No, I'm not doing features 6,7,8 till later. Yes, you can change you mind about what you want for later releases.
Lean emphasises quality and fixes cost while allowing time to change. You can get your burger for X dollars but you're 5th in the queue, you'll have to wait.
Traditional is about predictable cost, it (tries to) fixes time and allows change in quality to remain on budget. If everything goes to plan you should come in on time and on budget but maybe with less features or worse features than you wanted.
Of course, we know that traditional done badly produces over-budget, over-time projects that don't do what they were supposed to. It seems that agile methods are being used as cover for bad management because, as this entire thread is evidence of, there is widespread misunderstanding of the basics of project management. If you're going into an "agile" project and the requirements that you have are unclear then you need to kick up a fuss and hold the PM and the product owner to account. They should certainly be clear by the beginning of each sprint.