Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams


Like it or not, functional dependencies occur between requirements.  This can happen for many reasons, as we discussed in Managing Requirements Dependencies Between Teams, and there are several strategies for resolving such dependencies.  In this blog posting we explore what happens when a functional dependency between two requirements exists AND one requirement is implemented by an agile/lean team and another by a traditional/waterfall team.

In our example requirement X depends on requirement Y.  Neither requirement has been implemented yet (if requirement Y had already been implemented, and better yet deployed into production, the point would be moot).  When we refer to the “agile team” this team may be following any one of the lifecycles supported by DAD (Basic/Agile, Advanced/Lean, Continuous Delivery, or Exploratory/Lean Startup).


Scenario 1: An Agile/Lean Team Depends on a Traditional Team

In this scenario X is being implemented by an agile team and Y is being implemented by a traditional team.  From the point of view of the agile team, this is very risky for the following reasons:

  1. The traditional team is likely working on a longer time frame.  Disciplined agile teams produce a potentially consumable solution (potentially shippable software in Scrum parlance) on a regular basis, at least every few weeks.  A traditional team typically delivers a working solution over a much longer time frame, often measured in quarters.  The implication is that because Y is being developed by a traditional team it may be many months until it is available, compared to several weeks if it was being developed by an agile team.  This potentially adds schedule risk to the agile team.
  2. The traditional team may not make their deadline.  According to the Standish Group’s Chaos Report, the average traditional team comes it at almost twice their original estimate (e.g. a project originally estimated at 6 months of work takes almost a year).  Similarly, the December 2010 State of the IT Union survey found that traditional teams were much more likely than agile teams to miss their deadlines.  By having a dependency on the deliverable of a traditional team, an agile team effectively increases their schedule risk.
  3. The traditional team may struggle to deliver something that is “agile friendly”.  Agile teams routinely develop well written, high-quality software that is supported by a robust regression test suite and where needed concise supporting documentation.  Although traditional teams can also choose to deliver similar artifacts very often their code isn’t as well supported by regression tests and their documentation may be overly detailed (and thereby more likely to be out of date and difficult to maintain).  In other words, there is potential for quality risk being injected into the agile team.
  4. The traditional team may not deliver.  There is always the risk that the traditional team doesn’t implement Y, traditional teams often need to reduce the scope of their deliveries in order to meet their commitments, or if they do implement Y it is done too late to be useful any more.


There are several strategies the agile team may decide to take:

  1. Negotiate a delivery date with the traditional team. Once the agile team has identified the dependency they should collaborate with the traditional team to determine the implementation schedule for Y.  The agile team now has a release/schedule dependency on the traditional team which is a risk and should be treated as such.  The agile team’s high-level release plan should show a dependency on the delivery of Y and their risk log (if they have one) should also capture this risk.  The agile team should stay in contact with the traditional team throughout construction to monitor the progress of the development of Y.  The agile team should also attempt to negotiate early delivery of Y so that they may integrate with it, and test appropriately, as soon as possible.
  2. Collaborate to develop Y.  One way for the agile team to make it attractive for the traditional team to implement Y earlier than they normally would is to pitch in and help to do the work.
  3. Rework X to remove the dependency.  One of the general strategies discussed in Managing Requirements Dependencies Between Teams was to rework X so that it no longer depended on Y.  This may mean that you reduce the scope of X or it may mean that you deliver part of X now and wait to deliver the rest of X once Y is available.
  4. Reschedule the implementation of X.  Another general strategy is to deprioritize X and implement it after Y is eventually deployed.  This is a realistic option if Y is about to be implemented soon, say in the next few months, but often unrealistic otherwise.
  5. Implement Y.  When the lead time is substantial, the agile team may choose to do the work themselves to implement the functionality.  This can be viable when the agile team has the skills, experience, and resources to do the work.  This strategy runs the risk of Y being implemented twice, once by each team, potentially inconsistently.  To avoid this sort of waste the agile team will want to negotiate with the traditional team to take the work over from them.


Scenario 2: A Traditional Team Depends on an Agile/Lean Team

In this scenario X is being implemented by a traditional team and Y by an agile team.  From the point of view of the traditional team, this might be seen as risky for the following reasons:

  1. They may not understand how a disciplined agile team actually works. Many traditional teams are still concerned about the way that they believe agile teams work.  This is often because they perceive agile to be undisciplined or ad-hoc in nature, when the exact opposite is true.  The implication is that the agile team will need to describe to the traditional team how they work, why they work that way, and describe the types of deliverables they will produce.
  2. They may want traditional deliverables from the agile team.  Disciplined agile teams will produce high quality code, a regression test suite for that code, and concise supporting documentation.  Traditional teams may believe that they also want detailed requirements and design specifications, not realizing that the tests produced by the agile team can be considered as executable specifications for the production code.  The implication is that the two teams will need to negotiate what the exact deliverable(s) will be.
  3. They may struggle with any changes to the interface.  Agile teams are used to working in an evolutionary manner where the requirements, design, and implementation change over time.   Traditional teams, on the other hand, will often strive to define the requirements and design up front, baseline them, and then avoid or prevent change to them from that point onwards.  These different mindsets towards change can cause anxiety within the traditional team, the implication being that the agile team may need to be a bit more strict than they usually would be when it comes to embracing change.

The fact is that scenario 2, a traditional team relying on a disciplined agile team, is very likely an order of magnitude less risky than the opposite (scenario 1).   Either scenario will prove to be a learning experience for the two teams, particularly the one that relies on the other team.  Going into the situation with an open mind and a respectful strategy will greatly increase the chance that you’ll work together effectively.


Have any Question or Comment?

7 comments on “Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams

Valentin Tudor Mocanu

Very useful information.

Indeed, it is a high risk that an Agile team to depend on a “Waterfall” (it is better imho to use this term then “traditional”) because all the risks from the Waterfall are reflected to the Agile team results and finally the Agility could be “destroyed”. It is an anti-pattern imho.

Waterfall depending on Agile: with some good management, that could be an improvement for that Waterfall team/project, but imho, the first thing is to not allocate big projects/delivery to the Agile team, but a sequence of smaller sub-projects. Yes, could be a process ceremonial mismatch related to documents and information management that need to be solved in this case.

Anyway, what works better imho are the followings:
– Agile that depend on Agile
– Iterative that depend on Agile
An iterative project could use better results of Agile projects, and in fact could be an improvement for that approach. The ceremonial, also could be more easy to be matched.

I think that could be some generic conclusions:
– it is much better that all parts to be iterative (more ore less agile)
– the part that produce results for the other must be more Agile (an XP team could produce good results for a DAD or a Scrum team for example)
– the part that use the results should be more oriented on risks management and have support for enterprise awareness; and if it is Agile, it is better to be DAD and also use some Scrum practices like the Product Backlog and PG refining
– just as a consequence, the bigger (or equal) ceremonial should be on the part that use the results

I do not see any advantage on using Waterfall, in domain as software development. In most of the cases could be used Agile and other cases where risks, compliance and ceremonial are important, there are iterative approaches that give better results.

Valentin Tudor Mocanu

More: from my experience, in almost any context , there are parts, dependencies where the best approach, with the best result, it is an Agile approach. That mean it is better to be always ready to be dependent on Agile team !


I would add to the Scenario 1 risk list the quality risk and therefore potentially rework risk, which goes back to schedule risk as well. In the absence of feature Y, early integration will not be possible with all the well known consequences.


Scenario 2: A Traditional Team Depends on an Agile/Lean Team

I would add another point.

Most waterfall program plans to make their system test only at the end of the program, so they will remove most of the advantages developing a component the agile way.

In this scenario, a traditional project/program might only care on the shippable increment delivery by the Agile Team (date-driven), and because they are waterfall, they will probably miss the opportunity of testing the component incrementally in their system (value-driven).

The tradeoff is that traditional project depending of an agile team might develop a false sense of security toward the agile team because they seem to deliver according to dates only.


can agree to some thoughts. But not fully to all.
Instead I’m wondering more who in theses scenarios are the ‘customer’ of the result of x? And what is the companies construct, if they have such complementary teams working?
In any case I d expect to have an umbrella control to balance the bug target…


Henry, this is a very common issue in medium to large-sized organizations. A classic example is that one team is working on a system that provides web services that encapsulate some of it’s functionality that other development teams can reuse in whatever they’re building. Doesn’t have to be web services of course, could be any form of API or component strategy.


[…] To summarize, requirements dependencies do in fact occur.  There are strategies to minimize their impact, in particular implementing and better yet deploying the functionality that is being depended upon before the dependent functionality is implemented, but sometimes it just doesn’t work out that way.  So your team will need to be prepared to manage the requirements dependencies that it has on other teams, and similarly be prepared to support other teams with dependencies on them.  In this series of blog postings we’ve seen how Agile<=>Agile and Agile<=>Lean dependencies can be managed, next up is Agile/Lean<=>Traditional. […]

Leave a Reply

Your email address will not be published. Required fields are marked *