Coordinating Teams

When you have multiple teams working together, there are several ways to handle the resulting dependencies. Each has their trade offs, but I would rank them as follows:

1. Structure the teams so that a single team can solve the problem end to end
2. Do the work within the same iteration
3. Implement the service and then use it
4. Stub out the service and implement it later

Single Team

Ideally, you organize teams so that each can take on end to end stories. Organizing in this way greatly simplifies things. There is less coordination between teams. You're successful if the single team can implement the story.

The disadvantage is that organizational changes are difficult. There is organizational momentum with the current structure. The two teams might be so far removed that reorganizing is unlikely. Or one team might be outside the organization altogether (e.g., a partner). You might be able to make them part of the "virtual" team. If not, or if this is a temporary need or if organizational change isn't going to happen anytime soon, on to the next option.

Multiple Teams, Same Iteration

By both teams attacking their part of the item in the same iteration, you greatly reduce the risk that you end up half way done (adding no business value). You also reduce the risk that work is unusable. The two teams collaborate before and after iteration planning to ensure that they've signed up for the right work. They coordinate within the iteration to ensure that things are going well (a scrum of scrums does well for this). They demo together at the end. I'd recommend that the story is accepted or not as a holistic piece (i.e., either both teams succeed or both teams fail). This helps to align priorities.

Success is more difficult than with the first approach since both teams have to be successful to get the desired result. This approach is much more difficult if the teams are not on the same cycle (i.e., their iterations start and stop at different times) or if one of them is waterfall. If the latter, you'll need to get the team to at least work on this piece incrementally. Quality might be an issue as any other work that they're integrating with will likely not be in a "done done" state.

Multiple Teams, Service Provider First

If it isn't possible to synchronize the teams, you have to work on it one piece at a time. If this is the case, try to have the service provider do their part first. Or if there is not a clear service provider / service user relationship, focus on the part that will most likely get used even if for other purposes. This helps to minimize the chance that you produce something which goes unutilized (i.e., wasted work). It also reduces the amount of work that needs to be done since the service provider can usually be tested in isolation.

Multiple Teams, Service Provider Last

This is the choice of last resort. To accomplish it, you have to stub out the service. In other words, implement a stand-in that you can use for testing purposes until the real service can be implemented. This choice has the largest risk that work will be wasted. It also has the largest risk that rework will need to be done (as at a minimum, the stub will need to be replaced when the real service is created).

As a general rule, handle as many dependencies as possible using #1. If that's not possible, use #2. And so on. Approaching it in this way will reduce your complexity, increase your productivity, and will maximize the chance that you'll see business value out of the results.