That said, you get right to the heart of the matter: the interactions between kernel components are well established. Sufficiently so that one person can work independently on a subsystem and another on a driver.

In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first. They are very fluid and so it's necessary to be able to lean back and yell at the guy working on the driver or subsystem and say "yo, I need this additional parameter". On a distributed team you need to write that in an email and that extra effort is often seen (rightly or wrongly) as a major bottleneck.

Where I have seen companies fail to work successfully with geographically distributed teams, it has generally been because their "all in one room" culture has allowed them to establish an adequate process/culture around designing quality component interfaces in an efficient manner. This inability to define quality "contracts" is typically what leads to slipped projects and missed expectation. Often times, it is what plagues teams that are co-located.

If you can do a good job at defining system components and their interfaces, doing the development independently and distributed is easy. You can write test harnesses and stubs around those APIs. The question is: can you work on that design process in a distributed manner as well?

In my experience, it doesn't matter, local or remote. Designing component interfaces is hard work and hard to get right. But it is essential.

  In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first.