Earlier quoted context omitted.
This is a great piece. My software engineering training just held the assumption that the world runs on agile processes by now. Waterfall-like processes were a historical reference and a failure. Since external customers and non-swe stakeholders expect binding contracts and even waterfall, I would consider it essential to learn how to interface agile processes with the said contract-driven stakeholders. Telling them…
It's why contracted-for software is so awful - contractors do absolutely anything to meet the conditions and then they're gone and not responsible anymore.
What's the alternative? Never have contracted-for software? Only accept contractors who are prepared to do Agile?
How does the procurer then put out bids, without having requirements up front?
How do they evaluate bids from various suppliers without knowing what the final bill is? How do they shortlist the three "best" bids with no costing information? How do they even know if they can afford it?
How are the suppliers supposed to submit bids without knowing what they are going to bill for?
How does audit make sure that the process was fair?
Once you start supplying/developing software for companies that are large enough to have a procurement department, you better believe that the process all runs on paper[1].
[1] Or the digital equivalent.