[W]here my team fails is when we are all working on separate projects and we get bombarded with input from many other departments.
Scrum is designed to handle exactly the problem you describe. Specifically:
- Your team should be collaboratively working on a single project, not multiple projects. If you have multiple projects running simultaneously, you will need multiple teams.
- The roles of Product Owner and Scrum Master are designed to limit the negative impact of "bombardment" from outside the team. It is fundamentally the Product Owner's job to filter stakeholder requirements and manage them through the Product Backlog.
Change Control Enforced by Sprint Planning
Scrum is a framework that embraces change, but enforces change control by limiting most developer-facing changes to the Backlog Grooming and Sprint Planning phases of the project.
The sprint itself is a protected work zone that does not allow new work or changed requirements into the iteration. If a change is truly important enough to warrant an explicit termination of the current sprint and a return to Sprint Planning, then the Product Owner is empowered to do that.
The fundamental idea is that the project remains flexible, but that making changes within an iteration has a real cost that needs to be made explicit to the project and to its parent organization. It is the Scrum Master's job to educate the organization about this framework requirement, and to enforce the rules of Scrum within the team and with the Product Owner.
Stakeholders still get what they want, but it requires a shift in both stakeholder and Scrum Team behavior. See below for more specifics.
Adjusting Sprint Length
Keeping your sprint lengths short increase overhead and reduce the maximum size of the team's units of work. However, it offers the project more inspect-and-adapt cycles during the life of the project, so this is an area where each project must find its own optimum sprint length.