Whole Team

A whole team has everyone needed to take a story from idea to production. Not spread across departments. Not waiting on other teams. Everyone, together.

For software, this typically means:

• Developers (frontend, backend, full-stack)
• Testers/QA (if separate from developers)
• UX/Design (at least part-time)
• Product/Customer (available for decisions)
• Operations/DevOps (to support deployment)

The key principle: no handoffs. Work doesn't get "thrown over the wall" to another team. Everyone owns the full delivery.

Why? Because handoffs are where quality dies. The developer doesn't quite understand what the designer intended. The tester doesn't know what edge cases the developer considered. The ops team doesn't understand why the code needs that configuration. Every handoff is a translation, and translations lose information.

A whole team is cross-functional—the team has all the functions needed. But individuals don't have to be multi-functional (expert at everything).

You might have:

• A frontend specialist who knows some backend
• A backend specialist who can do basic ops
• A tester who can write simple test automation
• A designer who understands development constraints

The team is cross-functional; individuals are T-shaped—deep in one area, broad enough to collaborate.

Benefits of T-shaped people:

• They can help when others are bottlenecked
• They understand the full context of their work
• They can pair on cross-functional problems
• They grow their skills over time

XP encourages learning across specialties, not eliminating specialties entirely. The goal is collaboration and shared ownership, not uniform expertise.

XP originally emphasized physical co-location—everyone in the same room. While remote work has changed this, the principle remains: make work visible and communication easy.

An informative workspace shows:

• What the team is working on (visible board)
• How work is progressing (burndown, velocity)
• Where problems exist (blocked items, failing builds)
• What's coming next (prioritized backlog)

Anyone walking by (or joining a video call) should be able to understand the team's status at a glance.

Digital equivalents for distributed teams:

• Virtual Kanban boards (Jira, Linear, Trello)
• Dashboard screens in video calls
• Slack channels for updates
• Shared documentation (wikis, Notion, etc.)

The goal isn't the tools—it's transparency. Everyone should know what's happening without having to ask.

XP works best with small teams: typically 5-9 people.

Why small?

• Communication grows with team size (n × (n-1) / 2 connections)
• Small teams need less coordination overhead
• Everyone can know what everyone else is doing
• Decision-making is faster
• Accountability is clearer

If you need more capacity, consider:

• Multiple small teams working on different parts
• Teams organized around features or domains
• Shared practices and standards across teams

Scaling XP is a topic of its own. The key insight: don't make teams larger; make more teams. Keep each team whole and small.

Creating a whole team often requires organizational change:

Step 1: Identify all skills needed Map the path from story to production. Who's involved? What handoffs exist?

Step 2: Bring people together Move people (physically or organizationally) into a single team. This may require negotiation with other managers.

Step 3: Define shared goals The team succeeds or fails together. Not "devs shipped on time but QA found bugs" or "design was great but devs couldn't build it."

Step 4: Build cross-skilling over time Pair across specialties. Have testers pair with developers. Have developers do ops tasks. Spread knowledge gradually.

Expect resistance. Specialists may feel threatened. Managers may lose "their" people. The organization may not be ready. Whole teams require organizational buy-in, not just team-level change.