2.5 Cross-Functional Teams & Skill Diversity

2.5 Cross-Functional Teams & Skill Diversity

Scrum Guide 2020 Definition: Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

In traditional organizational structures, work flows sequentially through functional departments: business analysts draft specifications, UI designers craft visual mockups, software engineers write code, QA testers execute test plans, and operations engineers deploy builds. Scrum replaces this fragmented approach with cross-functional teams capable of taking an idea from concept to a usable, releaseable Increment within a single Sprint timebox.

---

Understanding Cross-Functionality in Scrum

Cross-functionality does not require every individual team member to perform every technical task with equal mastery. Rather, it means that the team collectively possesses all the skills required to turn Product Backlog items into a usable Increment of value.

Traditional Siloed Approach (Handoff Delays & Queue Bottlenecks)
[ Analysis ] ---> [ Design ] ---> [ Development ] ---> [ Testing ] ---> [ Deployment ]
  (Silo A)          (Silo B)         (Silo C)            (Silo D)          (Silo E)

Scrum Cross-Functional Approach (Collaborative & Concurrent Execution)
+---------------------------------------------------------------------------------+
|                                 SCRUM TEAM                                      |
|  [ Analyst ] + [ Designer ] + [ Developer ] + [ QA Specialist ] + [ Ops ]       |
|                                                                                 |
|                        ===> Usable Increment Each Sprint                        |
+---------------------------------------------------------------------------------+

Why Silos Fail in Complex Environments

• Handoff Delays: Waiting for external departments to complete review cycles introduces significant idle time and queue overhead.
• Loss of Context: Written documentation handoffs lead to misinterpretations, requiring costly clarification cycles and rework.
• Diffusion of Responsibility: When bug reports arise, functional departments often blame each other rather than taking shared ownership.

---

T-Shaped Skills and Skill Diversity

To maximize agility and eliminate bottlenecks, Scrum Teams foster the growth of T-shaped professionals:

                       Vertical Bar (|)
                Deep expertise in a specific
                domain (e.g., Database Architecture)
                              |
                              |
       Horizontal Bar (---)---|---(---)
       Broad knowledge & willingness to assist in 
       other areas (e.g., basic UI testing, story writing)

• I-Shaped Professional: Possesses deep expertise in a single domain (e.g., only writes backend Java code) but cannot or will not contribute to other tasks like testing or documentation.
• T-Shaped Professional: Combines deep specialization in a core area with a broad capability to assist in adjacent disciplines.

During a Sprint, if testing becomes a bottleneck, T-shaped Developers who specialize in coding step in to assist with writing test scripts or validating user stories. This flexibility keeps work flowing and prevents single-point-of-failure bottlenecks.

---

Skills Required for a Cross-Functional Team

Depending on the product domain, a cross-functional Scrum Team may require a diverse array of capabilities:

Every single one of these capabilities must be present inside the Scrum Team if they are needed to satisfy the team's Definition of Done.

---

Eliminating External Dependencies

A major topic tested on the PSM I exam is how Scrum Teams handle external dependencies.

The Problem with External Dependencies

If a Scrum Team must rely on an external "Database Administration Team" to run schema migrations or a centralized "Security Committee" to approve release builds, the team cannot guarantee delivery of a usable Increment by the end of the Sprint.

Empirical Scrum Solutions

1. Bring the Skill into the Team: Add a team member with the necessary security or database skills to make the Scrum Team truly self-sufficient.
2. Train Existing Team Members: Enable team members to acquire cross-functional skills over time through pairing and mentoring.
3. Automate & Delegate: Work with external teams to establish automated pipelines or standard operating procedures that allow the Scrum Team to execute tasks independently.

---

Sizing the Cross-Functional Team

Cross-functionality must be balanced with effective communication. The Scrum Guide sets clear guidelines regarding team size:

• Optimal Size: Small enough to remain nimble and large enough to complete significant work within a Sprint—typically 10 or fewer people.
• Scrum Team Composition: Includes 1 Product Owner, 1 Scrum Master, and Developers.
• Communication Channels: As team size grows, communication pathways increase exponentially ($N(N-1)/2$). A team of 10 has 45 communication pathways, whereas a team of 15 has 105 pathways, leading to friction and overhead.

If a Scrum Team grows larger than 10 members, it should consider reorganizing into multiple smaller, cross-functional Scrum Teams focused on the same Product Goal and sharing a single Product Backlog.

---

Common PSM I Exam Traps for Cross-Functionality

Trap 1: Component Teams vs. Feature Teams

Incorrect Scenario: An organization creates a "Frontend Team," a "Backend Team," and a "Database Team," calling each one a Scrum Team. Correct Scrum Behavior: These are component silos. A true Scrum Team is a feature team containing all frontend, backend, and database skills needed to deliver end-to-end customer value.

Trap 2: Separate QA / Testing Sprints

Incorrect Scenario: Sprint 1 is reserved for coding, Sprint 2 for testing, and Sprint 3 for deployment. Correct Scrum Behavior: Every Sprint must produce a usable Increment that meets the Definition of Done. Design, coding, testing, and integration must happen concurrently within every Sprint.

Trap 3: Outsourcing Testing to External Teams

Incorrect Scenario: The Developers finish coding and send the build to an external QA department for testing after the Sprint ends. Correct Scrum Behavior: Testing is part of creating a finished Increment. The Developers must include all necessary testing skills within the team to achieve "Done" status before the Sprint Review.

---

Summary Checklist for PSM I Candidates

• Cross-functional: Team has ALL skills required to deliver a usable Increment each Sprint.
• Eliminates handoffs, external queues, and departmental silos.
• T-shaped professionals enhance team flexibility and bottleneck resolution.
• Team size: 10 or fewer people to optimize agility and communication pathways.