That's why software organizations need to be modularized, just like code, so the small teams can work efficiently. But on the other hand, doing that just pushes complexity around. Instead of having a team chaos problem, you have an API and requirements chaos problem.
But on the other hand, doing that just pushes complexity around.
This. In my experience moving to small teams, service-oriented architecture, and semi-open allocation, the underlying problems of coordination were not solved. We had all sorts of issues coordinating API work and being blocked because one team's API was not performing up to par, but they were not fixing it because they had competing priorities. What ultimately helped get us moving again was getting a new engineering lead who had very good overall product judgement and could bang heads to get people on the same track.
If your app is intrinsically decoupled, then obviously small teams and SOA is a good idea. But if your app is inherently interconnected and requires coordination among complex pieces, then you are really choosing your poison either way.
Ultimately, I think the only proven solution for building high quality, complex software systems is to have Steve Jobs or another extremely talented and charismatic BDFL.
