Their work is complicated you see, there's all of these dependencies for every backlog item to be implemented and each task needs somebody with a special skill and we have to schedule how each person with the correct skill will finish each task in a certain order so I need some way of planning all of this and managing it within each sprint. Before you know it, there's gantt charts up on the walls and people are calling other people "resources". This is the reason why I keep my migraine medication handy at all times.
The problem here is that the very first assertion made here is absolutely true. Implementing a new feature in a complex system is complicated and there are certainly more factors involved than any one person can manage effectively.
Luckily the solution is actually rather easy. Make the management of this complexity as close to the work as possible, this actually means removing the project manager and allowing the team to decide for themselves how the work should be done.
Now almost as soon as you start doing this you'll begin to find impediments to the team getting their work done. The most major of these is that many new features and bugs need more than just a single person to complete them, at the very least you'll need somebody to code it and somebody else to test it but you may also need someone to modify a database or code a UI or design graphics or write up a help file.
To be clear, I actually don't agree with the approach of classifying developers by specific competencies. I feel like a developer should be able to code something into an application from beginning to end regardless of which part of the app needs to be modified. This makes development much easier, a complex feature may be developed by a single person and the only reason another person may be needed is for testing or pair programming.
I do realize that this is not always possible in every organization so I invite you to the middle ground: the self-organized cross functional team.
Cross functional means that the team as a whole includes everyone needed to implement any backlog item from beginning to end, including testing. This means that the team will consist of UI designers, Backend Developers, Database Administrators if needed and definitely testers.
Self-organized means that the team decides as a group how to implement those backlog items. This means that if a feature was started by Joe the UI developer but he needs something changed by Jim the DBA then all he needs to do is tell Jim to make that change when he gets a chance, no complex scheduling needed just individuals and their interactions getting things done.
Now in order for this to work you need a lot of collaboration between team members. Please note that this does not mean that the developers spend more time shooting emails back and forth, it means that they spend more time actually interacting. Preferably with real face to face communication.
In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be. Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.
In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be. Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.
You may also consider a couple other options for increasing collaboration (and therefore the team's ability to self-organize) by removing the cubicles and allowing the team to work in a single room with no walls separating them. This way if a developer needs somebody else for a particular change or task they can simply ask them without having to visit their individual office or cube. When doing this (or when deciding on teams in general) keep in mind your individual team sizes, a team larger than say 9 people will begin to find it difficult to communicate as a group effectively and you'll actually begin to hinder collaboration rather than help it. The ideal team size is 7 plus or minus 2 and the same should hold true for your team rooms.
Finally, it never hurts to encourage the team members to become cross functional as a whole. Introduce the team to pair programming. It's up to them to adopt it or not or to modify it into something that fits their own team culture but the more they can see of code outside of their own specialty then the easier it will be for their team to take on complex work.
