It's very important to manage dependencies in a large project, because the whole project will grind to a halt if too many people are waiting for (are dependent on) other people's output.

There are three ways to manage dependencies. If you run a big project, you will need to keep ALL of these mechanisms working efficiently. Projects fail when any one of these mechanisms gets jammed. Projects scale when they all work well.

1) Top-down planning

A manager must make a plan to ensure that certain tasks are finished first. This is always required for the big stuff. If you want a carpenter to come to frame a house, you need a plan to make sure that someone pours the foundation first. You can't expect the carpenter to arrange that after he shows up.

However, a project planner can't know everything. The team will need to figure out a lot of the plan and the dependencies while working. That is why we need peer-to-peer communication.

2) Peer-to-peer communication

In a smoothly-running project people and teams figure out what they depend on (what they are waiting for) and communicate with the people who can give them what they need. This is particularly important for projects facing unknowns, like those involving innovation or working with variable scope.

There are three major types of communication:

• Peer-to-peer communication. Each individual contacts the person whose output is needed. This is the most efficient method of communication.
• The big meeting. Everyone participates in a meeting, presents outputs they are waiting for, and gets help. This is the theory behind "Scrum of Scrums" meetings
• Escalation to management. People escalate dependencies to managers, who seek help from other parts of the organization. This might be necessary because people are not responding to peer-to-peer requests, or because nobody has been assigned to produce a needed deliverable. People can escalate needs with a message to their manager, or by raising an "obstacle" in a standup. Also, managers can run reports that show tasks that are likely to be blocked, and act on those.

We can make escalation easier by showing the problems that need to be escalated on a report. For example, it is possible to add a "relation" on ticket B that says it is waiting for ticket A, then run a report showing who is waiting for tasks that are unassigned or abandoned.

3) Fix it yourself

If something is important, you can fix it yourself, rather than waiting for someone else to do it.

The importance of this escape valve should not be underestimated. I think that it accounts for all of the improvement in scalability that open source projects experience over commercial projects. If you share code and responsibility, people can eliminate their own obstacles.

Most projects use a combination of these techniques. Big projects always require a project plan. New activities require communication. Important and easy tasks will yield to fix-it-yourself.

Do we need the Scrum of Scrums meetings? In my opinion, meetings are not required. We can handle everything that was not in the high-level project plan with peer-to-peer communication, organizational escalation, and the fix-it-yourself escape valve.