Hi, thanks for posting.

The structure you're after was considered early in the development of the grid system. Although there are advantages to it, it was rejected in favour of the current model for the following reasons:

1. A pool-based system doesn't allow the individual resources of nodes to be shared across multiple users. For example, if you have 6 users but 3 grid nodes, only 3 users would get a node, the rest would be left with no resources.
2. It's quite common that not all developers in a team will be writing code at the same time. If you have one of 6 developers working late at night, under the current model they enjoy full access to all grid resources with no machines sitting idle.
3. The system is designed to work with grid nodes of different hardware and software configurations. You might have both smaller and larger nodes. Running a pool-based system with such a setup would result in unfair distribution of grid resources.
4. DistributeByCapabilitiesAttribute, which can be used to split tests across nodes for multi-platform testing.
5. It's hard to efficiently manage a pool of resources without a central node to coordinate them. Right now we don't yet have the concept of a controller node (though this has been in the planning for a good long while now).

So basically, right now the product can't be configured to behave in the way you're expecting it to. However, what you can do is assign each of your developers to their own node in their own local configuration. If you have more developers than you have nodes, maybe some of them can share a node.