How to Manage Dependencies on Agile Projects: Agile Mentors Podcast 85

On Episode 85 of the Agile Mentors Podcast, host Brian Milner welcomes Ken Rubin to talk about how to manage dependencies on agile projects. Inside this video, you'll discover:
00:00 Who is Ken Rubin?
02:07 What are project dependencies?
03:45 Two types of dependencies on agile projects.
05:25 Where most agile teams go wrong with managing dependencies.
08:01 Why dependencies aren't the same as blockers.
10:45 Why do agile teams care about the concept of flow?
14:15 How to balance system-level work in process with capacity.
16:30 Options to solve dependency problems (hint: Feature teams don't solve everything)
28:15 Debunking the myths surrounding dependencies
For more details about Ken, how to manage dependencies in Scrum and agile projects, and Ken's upcoming "Dependencies Are Killing Your Agility" classes visit his website: learn.innolution.com/?ref=76f4e4

[@scottf9044]

your sticky note example really points to the importance of incremental development as much as the value of feature teams and reducing dependencies. If, with 3 component teams, one team can't get their work done there's no chance a feature team, with only a fraction of the component team, would be able to get that same work done within the sprint. For example, if 3 individuals on the component team can't complete the work there's no chance a single individual, now on a Feature team, can complete it. Thus, breaking that functionality down so that we can incrementally complete a portion of what's required, in order to get feedback, is just as important as removing the dependency. If you move to Feature teams, and continue to insist on doing huge implementations it will still take you just as long.

[@MountainGoatSoftware]

Yes breaking down work into pieces that you can complete and get feedback on is important. But creating a feature team doesn't mean that we reduce the number of people on the team. A feature team should have everyone necessary to deliver the feature. So in the sticky note example instead of having 2 separate teams (frontend and backend) we would have one team that has both frontend devs and backend devs working together to deliver the feature.
To your point about incremental work. If you had those 2 component teams, you could probably create 2 feature teams form them, each of which would be able to deliver entire features instead of half a feature per team. Just in that release cycle alone you'd double the amount of feedback from stakeholders (the more you complete and show to stakeholders the more they can actually provide feedback on).