Stop Calling It Cross-Functional If Work Still Waits on Another Team

By Jaehoon (Henry) Lee••8 min read

An agile cross functional team is a small, stable group that has all the skills and authority needed to deliver a usable product increment without handing work off to other teams. That means product, design, engineering, testing, and operational readiness are handled inside the team. If your “cross-functional” team still queues for QA, security sign-off, or a database change, it’s not cross-functional. It’s a handoff chain with standups.

The real problem is you’re measuring roles, not flow

Most teams misdiagnose cross-functionality as a staffing problem: “We have a designer and a QA, so we’re cross-functional.” But the failure shows up in the workflow. Work starts, then stops. Tickets pile up in “Ready for Test.” Releases wait on a separate DevOps queue. Security review becomes a monthly event. That’s not an agility issue. It’s a dependency issue.

The Agile Manifesto values “working software” and close collaboration, but it doesn’t say “assemble a list of job titles and you’re done.” Cross-functional means the team can finish the work it starts, inside the sprint or flow, without external gates. The Agile Manifesto is blunt about the goal: deliver working software early and often.

Scrum is even more explicit. In the 2020 Scrum Guide, the Developers are described as a cross-functional group with all the skills needed to create a usable Increment each Sprint. Not “access to” the skills. Not “alignment with” the skills. The skills are on the team.

Here’s the test that catches the truth: pick your last five completed user stories. For each story, count how many times it left the team (waiting on another team, another system, another approval board). If the median is above one, your bottleneck isn’t commitment or motivation. It’s structure.

Define cross-functional in a way your team can enforce

Write the definition in operational terms, then use it to make staffing and scope decisions.

Most definitions are too soft to use. So teams keep the label and tolerate the same delays. Don’t.

A working definition (AgileHour’s “No-Wait Definition”)

A team is cross-functional when it can take a backlog item from idea to production-ready without waiting on another team for core delivery steps.

  • Idea and scope: the team can clarify the outcome and acceptance criteria with a Product Owner or product manager present.
  • Build: the team can implement code changes in the systems it owns.
  • Test: the team can validate quality to an agreed standard, including automation where it matters.
  • Release readiness: the team can meet security, compliance, and operational checks as part of its normal workflow, not as a separate calendar event.
  • Deploy: the team can ship through its pipeline, even if a platform team provides the tooling.

That last line is where people get confused. Using a shared platform doesn’t break cross-functionality. Waiting in a platform team’s queue does.

The Atlassian definition of cross-functional teams emphasizes bringing the needed expertise together to deliver. That’s directionally right, but the enforcement mechanism is flow: can you deliver without handoffs?

Cross-functional doesn’t mean everyone does everything

It means the team has coverage. Not identical skill sets.

A useful pattern is “T-shaped” skills: each person has depth in one area and enough breadth to collaborate across others. You don’t need five full-time specialists for a five-person team. You need the team, as a unit, to close the loop.

Don’t overcorrect into role erasure. If you tell your only QA engineer to “just become a developer,” you won’t become cross-functional. You’ll just stop testing.

Start with the fastest fix: remove your top two recurring handoffs

Pick the two handoffs that slow delivery the most, then redesign around them this quarter.

If you try to “become cross-functional” by reorganizing the entire org, you’ll get a six-month initiative and the same blocked tickets. A better approach is to target the constraints you can see in your data.

Use your delivery metrics to find the delays. In most enterprise teams, cycle time balloons in two places: waiting for review and waiting for release. The DORA research keeps landing on the same theme: fast, reliable delivery comes from reducing friction in the software delivery system, not from heroics.

Do this in a 60-minute working session:

  1. Pull the last 30 completed items (Jira, Azure DevOps, Linear, whatever you use).
  2. Mark where each item waited on another team or an approval step.
  3. Count the top two wait states by frequency and by total days lost.
  4. Pick one structural change per wait state.

Concrete examples that work in real orgs:

  • If QA is a separate team: embed one QA engineer for 8 to 12 weeks, and shift automated checks into the team’s pipeline.
  • If security review is a monthly gate: add security acceptance criteria and lightweight threat modeling to refinement, then do spot checks, not blanket approvals.
  • If database changes are owned elsewhere: give the team bounded ownership of its schema or provide a paved path for safe changes.

One sentence of hard truth: if your “cross-functional team” can’t deploy, you’re running a feature factory, not an agile team.

Make cross-functionality real by aligning ownership to architecture

Align the team to a slice of the product that it can change end-to-end.

Many teams have the right people but the wrong boundaries. They’re staffed “cross-functionally,” then assigned work that cuts across five services owned by three teams. They can’t finish without coordination, so they regress into meetings and dependency boards.

The fix is to align teams to areas of clear ownership. Team Topologies calls this out directly: you want a stream-aligned team that can deliver value with minimal handoffs, supported by enabling and platform teams. The model is described in Team Topologies and it matches what most enterprise orgs learn the hard way.

Practical ownership rules that reduce dependency pain:

  • One team owns one meaningful customer journey or product slice, not a technical layer like “all backend.”
  • Dependencies must be explicit and designed down, not “managed” in a weekly sync.
  • Shared components need clear APIs and versioning so teams can move without coordination for every change.

This is where tools matter. If your release process relies on a human copying notes into ServiceNow, your team isn’t going to feel cross-functional no matter how many skills you add. The work will still wait.

Use a simple decision table to set expectations (and stop arguments)

Define what “done” means for your context, then use it to decide whether you need new skills, smaller scope, or different boundaries.

  • Scenario | What’s happening | What to do next
  • Work waits on QA | Testing is a separate phase or team queue | Embed QA temporarily, shift critical checks left, automate the top 5 regressions first
  • Work waits on release | Deployments require a central team or CAB timing | Create a paved path with the platform team, move approvals into policy-as-code where possible
  • Work waits on another service | Stories cross multiple team-owned systems | Reslice backlog to one ownership area, or change team boundaries to match the product slice
  • Work waits on decisions | Unclear priorities, unclear acceptance criteria | Strengthen product ownership, require testable acceptance criteria in refinement

Notice what isn’t in the table: “run a team-building workshop.” That’s fine for morale. It doesn’t fix structural waiting.

When the standard advice doesn’t apply: regulated, platform-heavy, or shared-infra orgs

Some organizations can’t fully internalize every skill into every team, and pretending otherwise creates unsafe workarounds.

If you’re in a regulated environment, you may have separation-of-duties controls. If you’re on a mainframe-backed estate, you may have a specialized release function. If your infrastructure is shared across hundreds of apps, you may have a central SRE or platform group for good reason. The goal isn’t ideological purity. It’s fast, safe flow.

In those cases, aim for cross-functional outcomes, not cross-functional staffing:

  • Define service-level expectations for external steps. “Security review within 2 business days” beats “security will try to help.”
  • Use standard templates and pre-approved patterns. A pre-approved Terraform module is faster and safer than bespoke review cycles.
  • Bring enabling experts into the team briefly, then leave behind capability. Team Topologies calls this an enabling team engagement model, and it’s often the only thing that works at scale.

If your compliance model requires an independent check, you can still be agile. You just can’t pretend independence equals slow.

The NIST guidance on building repeatable, risk-based practices is a useful reminder here: standardization and clear controls reduce variability. Variability is what creates “please fill out this spreadsheet” review theater.

A practical next step: run a “cross-functional readiness” review before you promise dates

Before sprint planning or quarterly planning, run a 20-minute readiness check on the top epics.

  • Can this team deliver it end-to-end without another team’s queue? Yes or no.
  • If no, what’s the dependency: skill gap, ownership boundary, approval gate, or tooling gap?
  • What’s the smallest change that removes the dependency this month?

Do it consistently for one quarter and the pattern will show itself. Most orgs discover they don’t have a “team performance” problem. They have an upstream planning habit that keeps injecting cross-team work into single-team commitments.

AgileHour’s editorial stance on this is simple and not negotiable: calling a team cross-functional while it routinely waits on other teams is organizational dishonesty. It blocks improvement because everyone thinks the goal is already met.

Start with the wait states. Fix the boundary. Then earn the label.

Sources

Enjoyed this article?
Get more agile insights delivered to your inbox. Daily tips and weekly deep-dives on product management, scrum, and distributed teams.

Daily tips every morning. Weekly deep-dives every Friday. Unsubscribe anytime.