Managing Requirements Dependencies Between Agile and Lean Teams

agile lean

Sometimes functional dependencies occur between requirements that are being implemented by different teams.  For example, requirement X depends on requirement Y and X is being worked on by team A and Y is being worked on by team B.  This generally isn’t a problem when requirement Y is implemented before requirement X, is a bit of an annoyance if they’re being implemented in parallel (the two teams will need to coordinate their work), and an issue if X is being implemented before Y.  For the rest of this posting we will assume that X depends on Y, X is just about to be implemented, and Y has not yet been implemented.  Previously in Managing Dependencies in Agile Teams we discussed strategies for addressing such dependencies, including reordering the work or mocking out the functionality to be provided by Y.  In this posting we explore the implications of managing requirements dependencies between an agile team and a lean team.

Managing requirements dependencies between an agile and lean team is similar to that of managing dependencies between two agile teams, although there are important nuances.  These nuances stem from differences in the ways that agile and lean teams manage their work.  Figure 1 depicts how agile teams do so, organizing work items (including requirements) as a prioritized stack (called a product backlog in Scrum).  Work is pulled off the stack in batches that reflect the amount of work they can do in a single iteration/sprint.  With agile teams the entire stack is prioritized using the same strategy, Scrum teams will prioritize by business value but disciplined agile teams are more likely to consider a combination of business value and risk. Figure 2 shows that lean teams manage their work as an options pool, pulling one work item out of the pool at a time.  Lean teams will prioritize work items on a just in time (JIT) basis, determining which work is the highest priority at the point in time that they pull the work into their process.  As you can see in Figure 2, they will consider a variety of factors when determining what work is the most important right now.

Figure 1. Agile work management strategy.

Work Item List


Figure 2. Lean work management strategy.

Work Item Pool


When an agile team depends on a lean team challenge is relatively straightforward.  Because lean teams take on work in very small batches, one item at a time, it gives them much more granular control over when they implement something.  As long as the agile team lets them know in a timely manner that the functionality needs to be implemented it shouldn’t be a problem.  For example, if the agile team is disciplined enough to do look-ahead modelling (an aspect of Scrum’s backlog grooming efforts) then they should be able to identify an iteration or two in advance that they have a dependency on the lean team.  At that point the product owner of the agile team should talk with the appropriate person(s) on the lean team to let them know about the dependency so that the lean team can prioritize that work appropriately (perhaps treat it as something to be expedited).

When a lean team depends on an agile team it’s a bit harder, but not much, to address.  This time the challenge is with the batch sizes of the work that the teams take in.  The lean team is taking in work in a very granular manner, one at a time, whereas the agile team is taking in work in small batches (perhaps two weeks worth of work at a time).  From a lean point of view this injects wait time into their process, even though it may just be two weeks, but this wait time is still considered to be waste (muda).  Once again the solution would be for the lean team to identify the dependency ahead of time via look-ahead modelling and negotiate with the agile team.

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.

Have any Question or Comment?

3 comments on “Managing Requirements Dependencies Between Agile and Lean Teams

Valentin Tudor Mocanu

Great topic !

About the dependencies…I definitely agree hat there is a connection between dependencies and the approach type. For example, I have solved some difficult process problems by switch to Agile and Lean (delivery life cycle) some parts that constitute dependencies for an an Iterative projects.
imho It is often very useful to switch small parts that constitute dependencies to an approach with a shorter delivery cycle.

Dependencies it is used below with this understanding: A depend on B means:
– A include B
– B it is a “detail” that need to be done in order to accomplish A

imho the “natural” dependencies occur when the ones with longer visibility and bigger “projects” (read delivery) depend on the ones with shorter delivery time and visibility.
That mean
– “Traditional” depends of Traditional & Agile that depends on Agile & Lean that depends on lean
Anyway, for software development, imho an Unified Process/Iterative approach should be always, at least as a life cycle, preferred to Traditional-Waterfall approach. I do not see any advantage on using Waterfall versus iterative. If we need planning and prediction, there is no reason to adopt a sequential life-cycle instead of iterative one.

The normal dependencies is imho like this:

– Iterative (UP) –> Iterative/Agile –> Agile/Lean –> Lean

If we want to extend to bigger endeavor could be:

– Spiral–> Spiral/Iterative (UP) –> Iterative/Agile –> Agile/Lean –> Lean

The chain could be shorter, or could have variations such as

– Spiral–> Agile –> Lean

Anyway, the natural order/hierarchy it is with possible by-passes:

– Spiral–> Iterative (UP) –> Agile –> Lean

I based my comments on some practical experience and not just on some logical combinations.

Valentin Tudor Mocanu

One more thing …requirements dependencies and dependencies in general are strong factors that could influence the process approach.
In my experience, the first switch to Agile was related to a such dependency. I have needed to move fast because a part of requirements in a big project was unstable and with often changes related to other parts. The emerging process and practices that manage that situation were from the Agile family.


Leave a Reply

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