Dealing with Team Dependencies in Agile-Scrum Software Methodology

Complex software development projects will have internal and external dependencies. The project itself might be getting executed by multiple teams. A typical example is that a product involving hardware, firmware and a software. And there is real customer value when all these three components are ready. There are three teams here, one for hardware development, second for firmware development and the third for software development. To carry out a potentially shippable increment, it should be decided that what work each different team will be doing in order to deliver the potentially shippable increment. A working software that the end customer can see.

In these kinds of projects, the (PSI) planning needs to carefully identify the dependencies among different teams once the features have been marked for execution in a PSI. The best way to handle these team dependencies is that making sure no one waits wanting some deliverable from other teams. This means that for example the hardware has to be ready ahead of time. Similarly the firmware has to be ready before the software development begins. (Assuming that prerequisite for software work to begin is the availability of hardware and firmware).

Sometimes, it makes sense to execute tasks in parallel. For example, both firmware and software can be developed parallel. If software requires firmware as mandatory input before the software runs, then something called firmware simulators/stubs can be created. So the software runs on simulated environment and Sprint Demo can be given. However, it cannot be claimed that the feature is completed unless all the dependent modules have been built and ready.

Its also the product owner responsibility to sequence the product feature priorities that have less or no external dependencies right in the PSI planning itself before the Sprint starts. Different product owners (across different systems) meet together and discuss the dependencies before they decide upon taking up a software work.

In spite of prior thinking and making best efforts to resolve the dependencies during PSI planning sessions, new dependencies may come up during actual execution of the tasks(during Sprint Execution). These dependencies have to be taken care during scrum of scrum (SOS) meetings that happen regularly between scrum masters of different scrum teams. And this is what is 'agile' exactly. Identify and resolve the team dependencies, capture problems faced during retro meetings and think what's needed to do differently in the next sprint so that the problems faced will not re-occur.