Agile is snake oil; Nu-softdev is a failure
Use the right tool for the job. RAD has its place, as does Agile.
Probably helps if software developers and QA are sent on Agile courses. It helped me. No system is perfect but as long as everyone agrees (Product Owner, Scrum Master and Dev/QA) on what the deliverables are each sprint generally it should work. Whatever doesn't work needs to be raised in retrospectives.
If Scrum isn't working for the team, consider Kanban.
I find Agile fails if the team is bad or you have a bad scrum master (my current situation).
...
How to make software great again: Create a new oppucation, the project demand mediator (PDM). Stakeholders then discuss, with the PDM, their user stories and visions. The PDM then steers the whole vision towards a coherent specification, which is then passed to the programming company (and not earlier). The programming company then makes a development plan, optimises it, and starts developing. The programming company can still give regular (every 25% of the way maybe?) status reports and presentations to the customer, they can then, via the PDM, make minor adjustments to the plan.
This way, almost all responsibility lies with the customer, and the programming company is actually kind enough to give status updates from time to time to give the customer the chance to detect their own failures early.
The PDM is a coder, but needs social skills. He knows how to understand the thought processes of different kinds of people. He knows how to moderate a discussion.
If there still are some parts of the specifications that are unclear, they will be left out, or a lowest common denominator of all possible approaches is chosen to be implemented.
Ah yes, if only the client were more considerate of the code monkey who's going to be punching the keys, rather than his own business needs, amirite?
It already exists; embed related. However, you're not going to see a lot of business analysts these days, because most code shops are domain-oriented and can therefore understand the client's needs without one, spending the money on something more useful instead. Again, it would be autist paradise to have a middle man to bridge every specialty, but budgets are a thing.
It's not about being considerate, it's about being efficient. Every failed iteration wastes time and money. Laying out the requirements to a reasonably complete state early on in the process makes sure the budget isn't wasted in unproductive developer time when it could be invested in something else.
Bullshit. Autists hate bureocracy. It's the normalfag managers who want to have more useless procedures in place.
That kind of scenario isn't so common but it does happen. For that scenario where the company's information processing requirements run on black magic, I would offer a couple of directions as solutions.
The first one is a matter of iterative prototyping of software to run for a few months. For example I'd continually write a series of protoype software for the period of six months. That is probably enough time to work out a reasonable set of specifications. I'd be writing the complete system after that time of exploration.
The second one is to break up the project into phases. In the first phase, I'll write a series of small tools that perform small and well defined tasks. These tools are not intended to be integrated into a single cohesive system. This process gives me significant insight about the requirements. If the system I've delivered adequately meets the business requirements, my job ends there. Otherwise, the next phase of the job is to refactor or recreate the system into an integrated whole.
Sure, but they also love to have a single-minded focus on actual programming.
waterfall means taking forever to release a new version
example: windows 98, then windows 2000
agile means releasing a new small update all the time
example: some app that gets updates multiple times per month, as opposed to slow and huge updates