How to deal with dependencies

The London Agile Discussion Group (LADG) held a meetup on the 28th of June with a focus on dependencies in agile teams. This was my first time at a meetup of this group and I found it quite insightful.

For this meetup we split into 2 groups, with 10-15 people per group. After a couple of 30 minute sessions discussing issues around dependencies, we had a third session to create a 10-point guide on dependencies, which the groups then presented to the other. These 10-point guides were organised via post-it notes and you can find their end results in the pictures below.

As you can see, some points stood out among both groups.

Empowered teams

Both groups vouched for the benefits of having an empowered team. The rationale behind this is that an empowered dev team will feel free to say “no” to the product owner if they find a problem with the order of the stories in the backlog, an empowered scrum master will be able to talk to other teams in order to resolve any blocking dependencies that occur mid-sprint, and an empowered product owner will likewise be able to talk to other product owners and stakeholders to re-adjust the backlog and expectations.

Improving communication

Improving communication between different teams was another point that both groups agreed on. And not the “frequent meeting to catch up” or “protocol to let other teams know what yours is doing” type of communication either.

The focus was in genuine human communication, such as going for a beer or some coffee with someone from another team and maybe discussing what they’re up to. In this sort of communication, anticipating dependencies takes a backseat to trying to get along in order to improve everyone’s willingness to collaborate when a dependency does occur.

Team composition

Both groups agreed that a cross-functional team, focused on features rather than components, is better able to handle dependencies as they will have all the skills within their means to do so. This means joining back-end developers, front-end developers, devops, designers, and even marketing people if necessary.

Clean architecture and code

Every developer wants to work with clean, spaghetti-free code, but non-technical people should be aware that this improves project agility as well, by eliminating both expected and unexpected dependencies.

Modular architectures enable deploys that don’t depend on other teams and results in less unexpected code dependencies. Aditionally, if a team needs to work on code that another team worked on before, having little or no technical debt means little or no dependency on other teams to resolve issues.

User story quality

User stories should be optimized to be free of potential dependencies. This can be achieved by having the team agree on the definition of done and the story’s boundaries. Additionally, smaller stories have smaller chances to create dependencies, as their boundaries will naturally be smaller.

Conclusion

Many of these points may seem natural and obvious, but many companies that claim to do Agile development and Scrum tend not to give the organisational support needed to follow them. Hopefully this meetup summary will help some Agile practitioner push for changes at their company.

I hope you enjoyed the read and feel free to leave a comment with your own thoughts about managing dependencies in Agile projects.

João Fernandes is a guest contributor