T-Shaped People and Shared Responsibility

Definition

In traditional hierarchies, teams are staffed with I-shaped people: deep expertise in one discipline (coding, testing, design), narrow capability elsewhere. This mirrors organizational silos and introduces risk—the "lotto factor" (if that person wins the lotto and doesn't return, we're stuck).

T-shaped people have a vertical depth—their chosen or preferred skill, where they excel—and a horizontal bar of diverse skills they can dip into to collaborate. More importantly, T-shaped thinking means understanding that in Scrum, the team's responsibility is to deliver whole features that are potentially releasable, not to optimize individual role performance. Testing is not the tester's job alone; it's a whole-team responsibility.

A good ScrumMaster encourages teams to share skills. A great one encourages teams to share responsibilities. The locus of accountability shifts from "I do this" to "we get this done."

In the Book

Watts describes the Geckos team, where developers and testers operated in silos. On day 28 of a 30-day sprint, developers finished coding the photo upload feature and handed it to testers. With only two days left and tests revealing a "can of worms," the testers couldn't finish. The feature failed, yet the burndown looked healthy. The problem: developers saw testing as "Roxie and Eve's job" and moved on to next-sprint work rather than help accelerate testing.

Marcelle, the ScrumMaster, confronted the team with a harsh truth: "We failed to deliver her priority #4 feature but managed to find time to work on her priority #9 feature." The question that unlocked change: "What makes you believe testing is purely Roxie and Eve's responsibility?"

Jeff Sutherland is quoted: "It is better for the developers to be surfing than writing code that won't be tested." If there's a bottleneck in testing, writing more code that can't be tested until next sprint is waste.

The solution: pair developers with testers so testing occurs during coding. Or implement kanban-like WIP limits (e.g., max two items "in test" at once), and when that limit is hit, the whole team "swarms" to unblock the bottleneck. One team created a "team initiation knowledge test" that every member had to pass, proving they could complete tasks in each discipline. They even had sheriff and deputy badges for each discipline.

Watts notes the organizational anxieties this surfaces: status concerns (if testers have lower status than developers), job security concerns (will I still be a "developer"?), career progression concerns. Great ScrumMasters navigate these carefully and often need HR and management support.

Why It Matters

T-shaped capability and shared responsibility break down the fragility of siloed expertise and the morale of narrow role identity. They enable faster whole-product delivery because there's no wait-state for a different specialty. The concept extends beyond software: any organization where handoffs between specialized functions slow work, or where the cost of a single point of failure is high, benefits from developing T-shaped members who can step into adjacent areas and share accountability for the outcome.