Your point about deadlines gets to the heart of the issue I think. Scrum and agile are flawed in many ways, but generally you can bend the methodology to at lea

Your point about deadlines gets to the heart of the issue I think. Scrum and agile are flawed in many ways, but generally you can bend the methodology to at least mitigate the issues. The one totally unsolvable existential problem, though, is the impedance mismatch between a team trying to be agile and a customer who's almost invariably not. The idea that your team can work on an open-ended basis with the customer to add functionality a piece at a time and dynamically adjust expectations as you gradually pin down the requirements and get a better idea of how much work they'll take, is, unfortunately, a fantasy. Somewhere up the chain, someone is going to want to know how much it's going to cost to get the features they want. The very best you can hope for is to estimate (ha ha) how long the milestone/project will take and then attempt to conduct scrum within that time box. But it's farcical and demoralizing because you end up structuring your sprints with what you know you need to get done instead of just what you think you can reasonably get done. The "agile" nature of it fractures the very first time you get behind your guesstimated schedule. I think the process could work if you win the lottery with a customer who's actually enthusiastic about embracing the uncertainty of agile, or if you work in a type of org that sets its own release schedule. But unfortunately I think those situations are rare and for most of us the fundamental mismatch between agile developers and non-agile stakeholders kill the whole idea.