TL;DR: Those SOPs are not Agile at all and suffer from all the shortcomings of traditional Waterfall projects. In Agile methods:
- Requirements are never frozen. Changing a requirement that isn't realized yet is cheap.
- Development & QA are close together, without any quality gates
- Projects are executed in short iterations, with feedback from the client(-representative) at the end of each iteration. This feedback can change what gets implemented next and the Scope of Work.
Those flowcharts describe a fairly typical Waterfall process, with all requirements being set in stone before the first line of code is written and the customer only seeing the final product.
The process does not seem to have any agility in it.
The process can work well if your client knows exactly what they want, but the only clients where I have seen that kind of up-front knowledge is if the client itself is developing its own products and has been doing that for a while.
If the client doesn't have the expertise to ask for a quote based on a full requirements specification written by them, then you need way more interaction with the client during development to get timely feedback on
- whether your understanding of the requirements still matches with the understanding of the client.
- how the partial solution they have seen has affected their vision for the final product.
All Agile methodologies are all built around being able to react quickly to changes in reality, including the reality that clients repeatedly change their mind halfway through. This is mostly realized by not setting anything in stone except the work that is currently being done. Especially the work that has not been started yet can be changed at a moments notice and without (big) consequences.
Another characteristic of Agile methods is that development and QA are tightly integrated, often to the point that testers and developers are in the same team. There is also no quality-gate between implementation and QA.
Some Agile processes have quality gates at the beginning of an iteration (Definition of Ready) and for when the work is completed (Definition of Done).
In a project-based organization, it is best to apply a iteration-based Agile process (like Scrum), because then you can have a Stop/Continue decision at the end of each iteration. Processes that are based continuous flow (like Kanban) don't have a natural point to do those decisions.
It is easiest to see how to apply Agile methods in a time/material project, because the client essentially buys a single iteration of work at a time. And with a typical iteration length of under 4 weeks, it is quite possible to get good requirements from the client for that amount of work.
But, it is also possible to apply Agile methods to fixed-price projects. The main difference with traditional Waterfall projects is that you don't agree on a set of requirements, but rather on a set amount of effort to create as much of the desired functionality as possible.
The amount of effort will be based on the initial Scope of Work, but the client should be able to make changes to the Scope of Work as the work progresses without going through a painful Change Request process as long as the remaining effort doesn't increase. So, the client should be able to say "On second thoughts, I don't need Feature X. Can you do Feature Y instead?" and not see an additional bill if Feature X wasn't implemented yet and Feature Y takes about the same or less effort.
As Agile processes embrace the fact that requirement will change during the implementation, there is no point in trying to discuss detailed requirements before the project has been awarded. It is better to keep the discussion on the level of features instead at that stage. The detailed requirements will come when you are preparing to start working on each feature (or not, if the feature ends up being scrapped).
