Share via

Dependency Management

  • Article

Microsoft is a big place with a huge number of software products in development and a number of those products have dependencies between each other.  We've got a pretty rich & consistent process for managing bug across divisions -- but managing software product dependencies (e.g. The Office team needs a component from Windows in order to ship) is a different story.  Some teams have built custom tools, some teams use Word documents and yet others use Excel.  The common theme about the process and the tool is that two teams are essentially creating a "contract" between them. It is certainly from the task-level dependencies that you'd often see in a Microsoft Project plan.

We've recently started managing dependencies more formally within Team System, so that the different product units (e.g. TFS, Team Test, Team Architect etc.) have a way of creating, managing and tracking the dependencies between each other.  Here's what a "Dependency" looks like:

Dependency

Some of the interesting fields:

  • Risk: To indicate a High,Medium,Low risk level for the dependency
  • Short status summary: For a human to take everything the system is saying and boil it down -- great for presentation in a table 
  • Iterations and dates: To mark out the delivery data from the producer and the expected use date from the consumer
  • Producers and Consumers links: To have the traceability to what features the dependency is delivered by and what it is consumed by
  • Producer and Consumer section: To have space for both sides to sit down and work out the details of the dependency

 The state flow is pretty simple:

  • The dependency starts off in Proposed and only needs Title to be filled out.  It can go to the Active state from there.
  • When it is in Active state, the producer product unit and description and consumer product unit and descriptions need to be filled out (the assumption is that if the dependency is active, at-least that information should be known)
  • From the Active state, it can to to a Closed state or back to Proposed or get Cut

Please share your feedback and I'd love to hear you are managing your dependencies and what additional support you'd like to see there.

Thanks,

-Siddharth

Comments

  • Anonymous
    January 31, 2008
    Siddharth, Thanks for sharing - I have loved getting a peek over the last couple of years into how the Visual Studio Team System team manages product development.  Obviously your system is very complex compared to the rest of us out here, but it is very interesting to see how you use TFS to attack some of the management problems around software development.  I loved the blogs earlier about Value Props, Experiences, etc.. as well as the posts/Tech Ed presentations by Brian Harry and Jeff Beehler.  This one continues that streak of good information and will cause me to rethink how I approach dependency management on my projects in the future.

  • Anonymous
    January 31, 2008
    Hi! Your comments are very much appreciated and we'll keep up the trend of giving you a peek into our process! -Siddharth

  • Anonymous
    February 02, 2008
    Siddharth, Very interesting feature!! How are dependencies defined? Can they be associated to work items and be rolled up to view for an iteration?  

  • Anonymous
    February 03, 2008
    Hi Siva, In this case -- to manage "contracts" -- in some sense, a heavy-weight dependency -- we created a work item type called dependency. It is possible to link the dependency to other work items and because the dependency has Iteration as a field on it, it is also possible to get a view by Iteration. -Siddharth

  • Anonymous
    September 16, 2008
    Thanks for the overview.  Can I get some more details?  I'm working with a large group at MS to deal with dependency issues.

  • Anonymous
    October 04, 2008
    A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast