This is a bug on TFS Integrator that was logged on TFS internal installation. They will get a fix out for this soon as they took the opportunity to use Windows Workflow Foundation (now that it is stable). Bug follows.
I suspect that Team Build is the problem here in that it doesn’t support queuing on its side of the fence. I uncovered this with the CrmOnTime project. The CrmOnTime project consists of three seperate builds CrmOnTimeCommon, CrmOnTime and CrmOnTimeServices. When CrmOnTimeCommon builds dependencies are replicated to the other two projects. If these projects kick off their builds at the same time they seem to fail if they are using the same build server. If they each kick off on a different build server then there is no problem.
Unfortunately we still have to implement the fix in our code because we are a Continuous Integration engine our users should rightfully expect not to have to run multiple build servers just to get multiple dependent builds kicking off - we just need to queue the requests. I’m thinking that moving forward we should replace the internal state management with an event driven workflow or something like that.
Structure the sleep periods such that you allow one build to complete before the other gets kicked off - or use multiple build servers.