17 August 2015
The best way to minimize dependencies is to have self-sufficient teams or ensure most dependencies can be resolved within the team. But if that’s not possible teams should try and identify dependencies as soon as or have the ability to raise dependencies across team using a common mechanism which works facilitates end to end visibility irrespective of the team structures and the underlying methodology the teams use. While this is easier said than done, following are some of the best practices people have used to try and manage dependencies.
The best way to resolve dependencies is not to have them!
While time-consuming, this is the best way to resolve dependencies. Project or program managers should build a cadence in which they meet all the project managers involved in their program. The structure of this meeting should be to talk about all the dependencies that are in progress, confirm that the dependencies they are working on are still priority, prioritize or re-prioritize new dependencies, and check how dependencies are adhering to the organization goals. This will also be a good time for every manager in the program to understand the amount of work the other teams have and then help each other out with resources or scope changes.
An easy way of removing dependencies is for “the team” to be made up of people with all the skills needed to complete the work needed. We often call these “full-stack” or “feature teams”. Teams that are building a product feature end-to-end reduce dependencies on external teams and individuals. They move quickly, add more value, and they reduce dependencies. If you can’t quite get to long-lived cross-functional feature teams, one very effective way to resolve dependencies is to have a person from the team on which you are most dependent “injected” into your team as a resource. This is often true for infrastructure, design and support teams but can be used in teams where one team is regularly dependent on another.
This technique requires all the product managers to provide a visual representation of their particular product feature backlog. Once that is done, the component project teams should only commit to in the following, in order of priority: a)Dependencies related to high priority features from an organizational standpoint; b)Features near completion; c) Features built on capabilities already present. For special situations when something needs to be done outside these three cases, a special team of experts should be formed and tasked with completing it.
While all these are preventive ways to manage dependencies it would be immensely helpful to find a software management tool that can do the following:
Although dependencies may be difficult to manage, they’re also inherent to larger, agile organizations with cross-functional teams. So if you look at it that way, in organisations where cross-team dependencies exist, having dependencies can be an indication that you don’t have silos and teams really are collaborating. The relationships between teams will dictate, to some extent, how well dependencies are resolved. So the more you can empower the teams, the more effectively teams can manage themselves. That said, it’s always best to anticipate dependencies when you can, and more importantly, see how dependencies may affect the delivery time and serving of business goals.
We have used the above-mentioned principles to try and help teams and managers better handle their dependencies. To see what we’re working on, try Mingle Plus 2.0 in preview here to see if something like it would work for your team. You can also give us feedback here.