> It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about.
That's where classic software methodologies such as Waterfall are good at: everything must be carefully discussed with the customer during the "requirements analysis" phase.
It is much more than that; the "Waterfall Model" SDLC is very much misunderstood. In fact the commonly used diagram for waterfall was an example of what not to do! Folks should read the following;
You know what would make us all faster? The entire team in a meeting talking about which JIRA tickets they moved yesterday and which ones they plan to move today. We should also ask the same in-depth technical questions on projects which we have already asked that developer a dozen times.
Why would that make us all faster? Also, is faster better, or better is better?
Waterfall development is the most appropriate way to develop software, most of the times. CRUDs developed by startups don't change requirements often, their clueless managers that change their minds as they get to understand what they should already know before starting the project.
That's a strange non sequitur. A statement against Waterfall is not a statement for Scrum (no reason to shout, I get that you don't like it but shouting its name is weird).
Please, point out non-trivial successful (delivered on time, on budget, and with all initially planned features) Waterfall projects that did not modify Waterfall into something sensible (that is, incorporated feedback loops and probably executed as a series of iterations rather than one 5-year long project with hard distinctions between each phase).
That's where classic software methodologies such as Waterfall are good at: everything must be carefully discussed with the customer during the "requirements analysis" phase.