I find that when you have many dependencies like this it 'breaks agile'. Basically you are forced to write a spec for the dependent system changes, even if it's just 'in your brain', based on your expected requirements for the end product. These then turn out to be wrong, or delayed, or dependant on another team, or whatever and muck up your sprint.
One way to get around this is to make your dependant services more generic. So instead of service.getCustomers, service.GetOrders for example you expand it to be service.queryAnythingDymanically.
Instead of DataAccessLayer.RunStoredProc you change to DataAccessLayer.ExecuteEntityQuery etc
This then reduces the situations where an upgrade to the dependant service is required by a 'front end' change.
There are downsides though. The more generic a service is the harder it is to test, performance may drop and security is harder to verify.
Another approach is to use a microservice architecture. This can reduce the difficulty of adding new features because rather than having to change an existing service you simply add a new one.
for example service1.getOrders -> service1.getOrders + service2.getNewStyleOrders
you still have to implement the features 'all the way down' but you are freed of some of the backwards compatibility and dependency concerns.
However, moving to this style of architecture is not as easy as it may seem. where before you had a clear service1.getOrders endpoint to connect to, you now have a more asynchronous message system, watch for lost messages, have to know what types your service can handle and ensure the whole thing is orchestrated etc