Cross-Functional Teams and Hidden Dependencies
Learn why cross functional teams still struggle with hidden dependencies and how Scrum teams can eliminate external handoffs to deliver a Done Increment every Sprint.
Most software organizations claim to have cross-functional teams. On paper, each team has a handful of programmers, a tester, and perhaps a designer. In reality, work still grinds to a halt every week because someone outside the team must review a database migration, configure a cloud cluster, or approve a release. The 2020 Scrum Guide defines cross-functional teams as teams whose members have all the skills necessary to create value each Sprint. When a team cannot ship without waiting on external gatekeepers, cross-functionality is merely an organizational label rather than an operational reality.
The False Comfort of Departmental Rosters
The common mistake is assembling teams based on job titles rather than the path of value. Managers put five backend developers, one frontend developer, and one quality engineer into a room and declare them cross-functional. But if that group still relies on a central security group to run vulnerability scans, or a central operations team to deploy code to staging, they remain fundamentally dependent on the rest of the company.
These handoffs create queues, and queues destroy flow. A developer finishes a feature in two days, but it sits in an external review queue for six days. Work in progress accumulates, context evaporates, and by the time the external party requests changes, the original developer has moved on to something else. What looked like a self-contained team is actually just one station on an assembly line.
Where Hidden Dependencies Form
Dependencies rarely announce themselves during Sprint Planning. They hide inside unspoken assumptions about how work gets done. You can usually spot them by observing where work stops moving:
- Infrastructure and deployment pipelines controlled exclusively by a separate platform or DevOps department.
- Architecture review boards that meet every two weeks to approve schema changes or technology selections.
- Specialized shared services such as security, compliance, or translation that act as final gates before release.
- Shared codebases where another team owns the repository and must approve pull requests before your code can merge.
Dependencies Disguised as Governance
Many dependencies persist because companies confuse governance with control. A security department wants to ensure code is safe, so they mandate manual audits before release. A database administrator wants to prevent slow queries, so they insist on writing all production migrations themselves. These policies begin with good intentions, but they cripple delivery speed.
True cross-functionality does not mean ignoring governance. It means shifting governance from manual inspection to automated guardrails. Instead of requiring an external security engineer to inspect every pull request, the security team can provide automated scanning tools and libraries that run directly inside the team pipeline. When the team possesses the tools and permission to satisfy organizational standards on their own, the dependency vanishes.
How to Build Genuine Autonomy
If you want teams that deliver a usable, Done Increment every Sprint, you must systematically eliminate these external links. Start by mapping every step required to take an idea from definition to production. Every time that path leaves the Scrum Team, you have found a dependency that threatens predictability.
You then have two choices. You can bring the required capability inside the team by training existing members or adding someone with that specialty, or you can automate the external check so the team can execute it independently. Cross-functional teams are not created by redrawing the organization chart. They are created by dismantling the handoffs that prevent people from finishing what they start.