One of the common problems software teams face is that they are not alone in the world, and usually depend on other teams to deliver functionality to the end customer.
When the two projects are happening at the same time, it gives both teams the advantage that they can communicate with and adapt more often to each other’s needs. It does bring a question on how to synchronise two independent streams of work, since not doing it might bring a lot of headache in terms of stories being blocked because dependencies haven’t been met, which ends up being a lot of waste.
In my current project, we have been using a visual technique to managedependencies which has been proven successful in terms of identifying dependent stories with minimal overwork.
- All stories that rely on external teams receive a red dot, which represents they can’t be played before the dependency is verified.
- Once the external team finishes their part of the work, a blue dot is written on the card, specifying the dependency can be tested by our team
- An integration test gets written against that feature, and if everything works as expected, the story received a green dot, showing that it is ready to be played
So far, the technique has reduced the feedback cycle between us and the external team on which we depend. Testing the stories just after they have been developed means that we can give early feedback about if they are working or not, and avoid starting to work in tasks that cannot be completed.