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.
Figure 2. Lean work management strategy.
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.
