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 Serial Team
In this scenario X is being implemented by an agile team and Y is being implemented by a serial/traditional team. From the point of view of the agile team, this is very risky for the following reasons:
- The serial 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 serial 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 serial 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.
- The serial 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 serial teams were much more likely than agile teams to miss their deadlines. By having a dependency on the deliverable of a serial team, an agile team effectively increases their schedule risk.
- The serial 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 serial 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.
- The serial team may not deliver. There is always the risk that the serial team doesn’t implement Y, serial 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:
- Negotiate a delivery date with the serial 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 serial 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.
- Collaborate to develop Y. One way for the agile team to make it attractive for the serial team to implement Y earlier than they normally would is to pitch in and help to do the work.
- 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.
- 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.
- 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 serial team to take the work over from them.
Scenario 2: A Serial/Traditional Team Depends on an Agile/Lean Team
In this scenario X is being implemented by a serial team and Y by an agile team. From the point of view of the serial team, this might be seen as risky for the following reasons:
- They may not understand how a disciplined agile team actually works. Many serial 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 seraial team how they work, why they work that way, and describe the types of deliverables they will produce.
- 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. Serial 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.
- 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. Serial 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 serial 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 serial 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.
