Scrum / Agile can have failure points both technically (code/development) as well as socially (requirements/planning). It sounds like you've seen a lot of social failure points in your experience.
I would hate to address all your complaints point-by-point, but I'll address the first which leaps out to me: that of a requirements phase prior to sprint start.
In the training I've gotten for scrum, there's an overriding principle that you don't (nay, can't) commit to work when you don't have all the dependencies. I can't commit to building a brick wall when the bricks haven't arrived yet.
If you have a hard requirement where you need/want to have an architecture phase prior to sprint start then you should be staggering your architectural planning phases with your development phases. In the current sprint you can be working the architecture requirements for the upcoming sprint, and developing off the requirements/design that was worked out in the previous sprint.
Overall, I think you've got some valid complaints but many that are misguided. I worked with someone who "just wanted to code" and didn't work to grasp the big picture. Much of what he did had to be re-done because it didn't meet the actual customer needs.
You would likely look at that and scream: "See, scrum doesn't work! We should have had a requirements document written 18 months ago that this code monkey could have worked from!"
I looked at it and said: "Wow, I can't afford to babysit this guy who has all the tools, information, and access necessary to correctly meet the customer requirements, but consistently doesn't manage to do so."
In the first case, you have more clarity up front but less flexibility while the work is in progress (front-loading work).
In the second case, we would have had to have two people doing the job that one person should have been able to do (incorrect delivery was a persistent problem with him which we worked over a year mentoring him on).
You are absolutely correct that scrum is a terrible methodology for building a bridge. And waterfall is a terrible methodology for building a startup.
Scrum/Agile (when properly used) has two main purposes... to better predict delivery of a particular technical capability (ie: when can I ship feature "foo" to customer "xyz"), and focus on keeping the product under development in a shippable state throughout the development process (ie: even though feature "foo" isn't done, I can still ship A, B, and C with minimal incremental work).
Waterfall is pretty much the opposite of incremental delivery, and in my experience does a poor job of predicting delivery dates.
If you are in a problem domain where you have hard requirements up front, a hard deadline, extremely well known technologies, then you are effectively building a bridge.
Break out the gantt charts, put a flag in the ground that says: "We're doing Waterfall" and be proud of it. But please try to avoid muddying the waters of scrum when you're using a tool for something it wasn't designed for and getting poor results.
My experience with agile/scrum is that it puts a more important bounding function on the product/biz side, where they place demands. The most effective scrum meetings I've seen have been where the biz side presents its desires, then the engineers give them actual level of effort, then the biz side decides _right then_ that they didn't care as much about this feature or that. That's an incredible improvement over documents whizzing this way and that, meetings, spreadsheets with LoE. Instead, just a quick meeting of minds.
"I want the blue button very, very badly."
"no problem. it will take three of us the entire scrum"
"my goodness, I didn't want it that much. Ok, punted."
"Scrum/Agile (when properly used) has two main purposes... to better predict delivery of a particular technical capability (ie: when can I ship feature "foo" to customer "xyz"), and focus on keeping the product under development in a shippable state throughout the development process (ie: even though feature "foo" isn't done, I can still ship A, B, and C with minimal incremental work)."
A lot of people think that those are the core purposes of agile.... and that's part of the problem.
The real core purpose of agile is shortening the feedback loop. If you aren't shortening the feedback loop you are wasting your time.
I would hate to address all your complaints point-by-point, but I'll address the first which leaps out to me: that of a requirements phase prior to sprint start.
In the training I've gotten for scrum, there's an overriding principle that you don't (nay, can't) commit to work when you don't have all the dependencies. I can't commit to building a brick wall when the bricks haven't arrived yet.
If you have a hard requirement where you need/want to have an architecture phase prior to sprint start then you should be staggering your architectural planning phases with your development phases. In the current sprint you can be working the architecture requirements for the upcoming sprint, and developing off the requirements/design that was worked out in the previous sprint.
Overall, I think you've got some valid complaints but many that are misguided. I worked with someone who "just wanted to code" and didn't work to grasp the big picture. Much of what he did had to be re-done because it didn't meet the actual customer needs.
You would likely look at that and scream: "See, scrum doesn't work! We should have had a requirements document written 18 months ago that this code monkey could have worked from!"
I looked at it and said: "Wow, I can't afford to babysit this guy who has all the tools, information, and access necessary to correctly meet the customer requirements, but consistently doesn't manage to do so."
In the first case, you have more clarity up front but less flexibility while the work is in progress (front-loading work).
In the second case, we would have had to have two people doing the job that one person should have been able to do (incorrect delivery was a persistent problem with him which we worked over a year mentoring him on).
You are absolutely correct that scrum is a terrible methodology for building a bridge. And waterfall is a terrible methodology for building a startup.
https://crossbolt.files.wordpress.com/2013/11/when-to-use-sc...
Scrum/Agile (when properly used) has two main purposes... to better predict delivery of a particular technical capability (ie: when can I ship feature "foo" to customer "xyz"), and focus on keeping the product under development in a shippable state throughout the development process (ie: even though feature "foo" isn't done, I can still ship A, B, and C with minimal incremental work).
Waterfall is pretty much the opposite of incremental delivery, and in my experience does a poor job of predicting delivery dates.
If you are in a problem domain where you have hard requirements up front, a hard deadline, extremely well known technologies, then you are effectively building a bridge.
Break out the gantt charts, put a flag in the ground that says: "We're doing Waterfall" and be proud of it. But please try to avoid muddying the waters of scrum when you're using a tool for something it wasn't designed for and getting poor results.