Dependencies become important in a big software project. A dependency happens when one person is waiting for another person to finish something. In my series on vanquishing the Mythical Man Month, have argued that this is the single biggest reason why big teams are slower (per person) than small teams. One person is never waiting for himself, but in a large project, there can be a LOT of people waiting for something.
Many organizations find and manage dependencies with big meetings, scrum of scrum meetings, or long and painful conference calls. As a distributed team advocate, I believe that it is possible to run a complicated project, with many dependencies, without having large group meetings. What a relief!
There are three ways to manage dependencies.
1) Planning: A manager figures out all the dependencies and makes a plan to get the first things 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.
2) Communication: People and teams figure out what they depend on (what they are waiting for). Then, they communicate with the people that can give them what they need. This is a sort of bottom-up process. You need to do this for anything un-anticipated, so it will be required if you are innovating, or working with variable scope. There are three major types of communication
- Have a big meeting where everyone can present the things they will need or are waiting for, and get help. This is the theory behind "scrum of scrums."
- Peer to peer. Each individual contacts the person or people that they are waiting for.
- Escalation. You can tell a manager that you have a problem and get help from the organization as a whole. This will be required if it is not clear that there is anyone responsible for the thing you are waiting for. You can do this with a direct communication, or by raising an "obstacle" in a standup. Or, managers can run reports that show tasks that are likely to be blocked, and act on those.
3) Do it yourself: If something is important, you can do it yourself, rather than waiting for someone to do it. I have often heard people argue that this is inefficient, because it results in two contributors working on the same thing. To me, that seems like a very small inefficiency, compared with waiting around and blocking many people from working. 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 your code and responsibility, people can eliminate their own obstacles.
Most projects use a combination of these techniques. Big things will always require a project plan. New things require communication. And, important or easy things will succumb to do-it-yourself.
So, do you need the Scrum of Scrums meetings? In my opinion, meetings are not required. I think that we can handle everything that was not in the high level project plan with peer-to-peer communication and organizational escalation.
A social work environment like Assembla makes peer-to-peer communication easier.
We can make escalation easier by showing the problems that need to be escalated on a report. For example, it will be possible to add a relation on ticket B that says it is waiting for ticket A. Then you can run a report that will show tasks that are in the Current work bin, which are dependent on tasks that are not in the Current bin, stuck in one status for more than a week, marked as a lower priority, not assigned, etc. If you signal what you are waiting for, I think the system can figure out if a problem is developing. Then, you can solve the problem directly, rather than in a big meeting.