That's definitely true at the organizational level, and it's an argument with some merits.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".
that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together
They ALWAYS need to be building and developing the feature together or this happens. Decent API design without deep understanding of Client implementation or performance needs is nearly impossible.
They generally should all be in the same team, but that often doesn’t scale.
Not having them in the same team pretty much never works well though either.
In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!
My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".