Pretend the Waterfall team is an outside contractor
Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you.
The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for ...
First of all, make it known to your stakeholders that there is a project risk in your project. The waterfall team is asking for things (final, unchanging requirements) that you don't have at the start of your project.
To mitigate this risk, you can analyse your current backlog for items that may affect the data that you need to exchange with the system ...
This is an unenviable position. I'm not sure there are any good/easy answers.
Who is accountable in this scenario?
Who approves the changes? Changes (last minute or not) have a financial impact on the company.
What is the change control process? It isn't clear whether the 3 PM's who communicate with the clients have the authority to unilaterally ...
I have been in this situation a couple of times and it is very challenging.
Things that can help:
Spend some time with the waterfall team explaining how you work. Even if you can't resolve the conflicts between the approaches it still helps if they understand what you are trying to do.
Ask them to produce a mock/stub at the earliest opportunity to at least ...
There are two parts to your question:
Do the clients really need to make changes at very short notice
If this is a real need, what do we have to do to respond to changes very quickly
I would start by speaking with the clients and explaining the impact of last minute changes, which might include:
Efficiency lost due to context switching (i.e. shifting to ...
For what it's worth, APIs and protocols are an area you often do need things fixed. This has to be very deliberately and explicitly designed because if you need to change it later, every consumer will have to update their code. APIs which are often changing are a nightmare to work with especially if they implement backwards incompatibilities.
I do not see a ...
They are also strict. No changes to the requirements. They want to lock down the requirements.
That is not really true though. They would like to restrict changes to the requirements, for sure, because that's the nature of waterfall development. In practise though it is never possible to avoid some changes to requirements, because issues will always occur ...
When the API is not too complex, you could create your own mock API to experiment with which returns test data. When you got your requirements down, you can contact them to create a real API delivering real data.
Without understanding fully, I don't think we can suggest the best approach. With that in mind, here is my approach based on the information given.
1) Remove the concept of 1 week development, 1 week testing. It should be test as soon as developed, fix bugs as soon as it is tested. This will ensure that your deliveries have as little amount of bugs as ...
If you can make this work for your teams then that is fine.
I would caution that a global definition of done has several drawbacks, including:
Getting consensus over several teams is challenging. If not all the teams agree with the final solution then they may ignore it or work around it.
Some aspects of the definition of done may be specific to each team.