In the “old days” of waterfall development, upfront investment in thorough design specifications meant that functional dependencies in the design were identified early by the Technical Architect and scheduled appropriately by the development manager. Rigorous change control ensured that new requirements were vetted and simply parked if they would inject significant new dependencies.
A new breed of dependency is unique to the agile environment. Within the scope of a single application development, pieces of functionality being developed by one team may have dependencies on functionality being developed in parallel by another team or teams. To complicate matters further, each of those secondary dependencies may have their own dependencies on a third or fourth level of functionality possibly in the streams of yet more teams. It can get very complicated.
Because the teams are charged with delivering value with each sprint or release, re-prioritizing the workflow to cater for these dependencies “owned” by other delivery teams is not intuitively an attractive proposition. Something has to give to achieve timely delivery.
Functional dependencies are raised by three primary instigators:
Business requirements – Use cases illustrate activities by end users, which are usually the primary drivers for functionality in the majority of applications. Raising a ticket in a help desk ticketing system requires that the user’s account be opened first, and the relevant categorizations for assigning the ticket have been implemented and populated. The resolver teams need the functionality to channel the tickets into the right queues, and so on. The flow has a multitude of functional dependencies.
Package breakdown – Large requirements (epics) are broken down (decomposed) into smaller work packages (stories) and the dependencies that existed across the large requirement are inherited by the smaller packages.
Integration and Technology – Standalone applications are rare in the enterprise landscape. A new development is likely to need links into existing applications, databases or technologies of one form or another. The business requirements may dictate a change to existing rules or processes. Each one is a new dependency or may be a dependency chain whereby several components need to be modified to deliver a single new dependency.
The first two types above can be handled by the Product Owner. The simplest scenario is where the dependencies are between work items being developed by a single team as this can be easily resolved.
Integration and technology dependencies require the expertise of the Architecture Owner role in Disciplined Agile Delivery to advise the Product Owner about the intricacies and implications of other applications and technologies. Frequent consultations with the Architecture Owner are essential, not just at project inception but also for planning each release and look ahead planning throughout the lifecycle.
The three most commonly recognized techniques are:
Reprioritizing the requirements is the least costly option because there is no extra work for the development teams. A management view needs to be taken and allowances made for potentially reduced value in the scheduled deliverables of one or more teams s they are now not working on the most valuable elements in order or priority.
Building a stub to emulate the missing functionality is a pragmatic and reasonably elegant option. However, the total functionality cannot be delivered until the missing dependency has been developed and tested to replace the stub.
Redesigning the dependent functionality to merge two or more components into one will resolve the dependencies. The potential downside is a reduction in the ROI of the team charged with this development.
As mentioned above, resolving cross-team or cross-project functional dependencies is relatively straightforward where dependencies reside in one team or one project. It is also mitigated when one dependency in one team or project has a dependency on functionality that has already been developed by another team or project. This holds true even across a program of projects where each project has a different Project Owner. The principles are the same.
Likewise, where a functional dependency in one stream or project lies with as yet undeveloped functionality in another, the Product Owners must negotiate agree to utilize one of the three techniques described above. There may be challenges, such as the team velocities being very different because of factors such as team size and different productivity and efficiency levels.
However, the principles remain true, whether the dependencies lie across teams in a single project or across multiple projects in a program.
The key principle that Product Owners should bear in mind regarding dependencies is to expend the bare minimum of effort to cater for them while retaining tight visibility and control of each one in some detail. Adopt a JBGE approach (Just Barely Good Enough) because anything more is a waste of effort and resource.
However, it is vital to keep tabs on dependencies, especially when performing a work package breakdown. This is where aspects of dependencies can get lost, only to resurface later and cause significant disruption to the best laid plans. The three most popular approaches for managing functional dependencies are:
A physical dependencies map – In the days before the proliferation of agile tools, post-it sticky notes or cards were arrayed on a wall, whiteboard or corkboard, or even on a large desk. Physical devices were used to indicate and highlight dependencies, such as conventions for positioning dependencies to the right of requirements, or drawing lines or using strings to interconnect dependencies to functionality. This is quite a valid approach for smaller projects or for a “first look” at a project.
Basic tools – Excel has been used successfully as have other electronic tools such as Word and Visio.
A backlog and requirements management tool – Using a state of the art tool like Agile User Story Map for JIRA is the next generation for fast and efficient dependencies management. This fast and easy to use approach provides additional benefits such as:
Centralized specialist tools, such as the Agile User Story Map, provide a view to teams who may be dispersed across the globe. All stakeholders can share the view, which provides an at-a-glance status update and highlights complexities and dependencies in a clear visual manner. The Agile User Story Map is a cost effective productivity enhancer with a shallow learning curve that can be providing major benefits to your teams within 24 hours.