What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!
If you can get a bunch of people into a room and plan out what everyone on a software team is doing for the next three months, there's a pretty clear cap on how creative or adaptable the work can be. What is everyone doing for the rest of the quarter? "Executing"? Just filling in the "obvious" implementation details to program exactly what they're told?
Getting a clearer picture of the next 3 months should be a piece of cake. As a bonus once it’s planned you should get to focus without a sudden shift in priorities.
(Note: quickly, not suddenly. Bad performance in market validation should never come as a complete surprise. It always slowly dawns on you over the course of days/weeks.)
Another reason for changing priorities quickly is that the specification drawn by the product team happens to be technically very complex because it interacts in unforeseen ways with other functionality, and this is discovered early in implementation.
Basically, in product development, you're constantly running into things that either provide less value than expected, or cost more than expected. That's when you should do something else instead.
Once you have a great idea, yes, you should sink all of your effort and focus into that to get it to market quickly. But the idea is that if you start cautiously and change your mind early and often, you can actually implement the winners with blazing speed later without looking back.
Which is most orgs I've worked with.
On the estimation side of things, I've worked with teams that do estimates in concrete hours, days, weeks, etc, and teams that work in abstract feature points, bushels, etc. The number one factor for whether the estimates are successful is the time spent before providing the estimate to figure out what the actual scope of the task is. If you've planned and estimated a task and didn't discover the cross-team dependency during that planning, you've failed at planning. It happens. It sucks. It should be very rare.
I've worked with teams where "sprint planning" every two weeks/whatever cadence is basically an entire engineering team getting pulled into a room for a morning, the manager/scrum-master/whatever pulls up their backlog and starts picking tasks off the top. The team is expected to provide estimate efforts on the fly in the meeting, and then expected to spend the next two weeks perfectly executing on the work they've committed to. How in the hell is a process like that going to allow people to really think through the issues that are going to arise (like needing an API change on another team, or even verifying that a 3rd-party API is compatible with what the task is trying to achieve)? These teams constantly run into the issue you've described and it absolutely sucks for everyone (the business, the managers, the developers), but the process just keeps being adhered to. Maybe in the post-mortem someone will say "we need to do a bit more analysis before doing estimates", and the outcome is that during the next sprint planning session the SM will say "HAVE YOU REALLY REALLY REALLY THOUGHT THIS THROUGH?" but... they're still doing analysis on 12 new tasks blind...
This requires teams to have slack/contingency time in their plans. That’s important.
Of course, there will always be situations where you don’t spot a dependency until you start coding. But in the loosely-coupled mode, that is what happens every time you have a dependency on someone else, ie you have no opportunity to spot in advance. Worth some planning exercise you get an opportunity to spot the dependency and deal with it gracefully, even if you don’t catch 100%.
But yeah, if there is no benefit to spotting early because the other team doesn’t have slack for the Q, then less point in planning in advance.
Different code bases in the org might even have different process certifications they have to follow, eg in medical software or some other industries. In those cases it’s downright impossible/illegal to give every team access to every repo.
SAFe is supposed to solve this. I haven’t heard anything good come out of it though so far, so I find this thread very interesting.
At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.