When we take a dependency in Visual Studio or in the .NET Framework we're doing two things.
First, we're taking a commitment from a team to deliver a set of features into the product.
Secondly, we're taking source or binaries from that team and technically integrating it into the product.
The latter can be expressed in a dependency graph, and there are plenty of tools that we can use to discover static dependencies. The former involves people and needs to be carefully managed. I talked a bit about how DevDiv is using TFS Work Items,which we
call our Feature Directory, to track features. Program Managers enter "commitments" on other teams as dependencies in the Feature Directory. We can report on features and look for schedule alignment and misalignment through TFS reporting. But ultimately, we
manage feature dependencies by making sure our commitments are aligned.
Yes, we did MQ post VS2005 release. This is the first time Developer Division has ever done this, and we had a lot of catching up to do. We used MQ to improve our engineering practice and to get our tools and codebase into a place where all code that gets
integrated into our "main" build is ship-quality.
The core team responsible for managing the MQ release just recently discussed the MQ milestone on Channel9. Here's the link: