Waterfall - Agile team cooperation

January 2, 2007 by Artem

When agile software development is tried in a large corporate environment, it often happens that the agile pilot team or even teams have to cooperate with the old good waterfall team around the corner. It sounds reasonable that the new things (like the agile process) is tried first on the project of not too big importance, that are supposed to add value to the more important activities. For example, an agile team might be asked to develop a web-interface to the client-server system being developed by a waterfall team.

I don't have an experience with a really hard dependency, but I've been in a situation when our dependency on a waterfall team was rather weak. What happened is that the waterfall team tried to delay the integration as long as possible (our fault that we did not force it to happen earlier) and as a result the whole product has been delayed a bit.

Agile pressure

From a limited personal experience of this kind of collaboration and from rumors around I can say that most often the agile team puts the pressure on the waterfallish partner. Since agile teams often practice test driven development and write tests for the external interfaces also, bugs in the waterfall component are discovered much earlier and more frequently, than the waterfall team is comfortable with. Since agile teams are ready to change according to the changing (or more clarified) customer demands, extra pressure is put on the waterfall team to change their plans much-much earlier, than they would like to. And so on, and so on.

Virtually in any case I can imagine the agile team puts the extra pressure on the waterfall team. After that everything depends on how well the pressure can be resolved and how much of politics has to be involved. The possible outcomes could be:

• The second team sees at least some value in the agile team arguments and adapts at least somewhat. For example, that could move from the strict waterfall to the phased delivery, that is a good first step to the agile process adoption.
• The second team (or its boss) claims that the agile team is disrupting the orderly business and then the situation mostly depends on the political powers of the team chief and the position of a higher management. In extreme cases the agile team can be even shut down

Own experience

Did you experience this kind of an agile-waterfall collaboration in real life? I wonder what most frequently happens in reality, especially in situations with the strong inter-team dependencies.

Permalink