11  Building Agile HR Teams

ImportantLearning Objectives

You will be able to:

  1. Design the composition of an agile HR team: small, cross-functional, T-shaped, and organized around an outcome.
  2. Explain what the evidence says actually makes teams effective, and why psychological safety outranks talent density.
  3. Build the working agreements, cadence, and decision rights that convert a group of specialists into a team.
  4. Institutionalize the iterative mindset and continuous improvement so the team keeps getting better after the launch energy fades.

11.1 Introduction

The previous four chapters redesigned HR’s core processes; this chapter turns to the unit that runs them. Every practice in Part II presumes a particular kind of team behind it: the hiring squad of Chapter 7, the collaborative reviewers of Chapter 9, the OKR-setting group of Chapter 10. None of these exist by declaration. A collection of specialists who share a manager and a mailing list is not a team; it is a distribution list with meetings. Building the real thing, small, cross-functional, self-improving, is itself a design problem, and this chapter treats it with the same rigour the earlier chapters gave to recruitment or performance (Natal Dank & Riina Hellström, 2020).

The chapter proceeds in three layers. Composition: who is on the team and what shape their skills take. Conditions: what the evidence, rather than folklore, says makes teams effective. Operating system: the agreements, cadence, and improvement loops through which flexibility and the iterative mindset stop being aspirations and become habits. Throughout, the object is the HR team itself, the function must live the model it recommends, a credibility point the ING case of Chapter 5 already established.

flowchart LR
    C["Composition:<br>small, cross-functional,<br>T-shaped"] --> N["Conditions:<br>psychological safety,<br>dependability, clarity"]
    N --> O["Operating system:<br>agreements, cadence,<br>decision rights"]
    O --> I["Improvement loop:<br>retrospectives, kaizen"]
    I --> N
    style C fill:#e3f2fd,stroke:#1976D2
    style N fill:#e8f5e9,stroke:#388E3C
    style O fill:#fff8e1,stroke:#F9A825
    style I fill:#ede7f6,stroke:#7E57C2

11.2 Composing the Team

11.2.1 Small, Cross-Functional, Outcome-Owned

Three composition rules carry from Part I. Small: the coordination cost of a group grows with every added member, which is why agile practice converges on teams a couple of pizzas could feed, roughly five to nine people, large enough to hold the needed skills, small enough that everyone knows the state of the work without a status meeting (Ken Schwaber & Jeff Sutherland, 2020). Cross-functional: the team contains every skill its outcome requires, a recruiter, a people-analytics specialist, a learning designer, an HR business partner, so that work finishes without leaving the room, removing the hand-off queues Chapter 6 identified as the deep cause of slowness. Outcome-owned: the team is organized around a product or mission, the onboarding experience, the leadership pipeline, not around a shared specialism, and it holds the delegated decision rights Chapter 3 established as the difference between genuine and nominal autonomy (Darrell K. Rigby et al., 2020).

11.2.2 T-Shaped People

Cross-functional teams stay small only if their members are T-shaped: deep in one discipline, the vertical stroke, and capable across neighbouring ones, the horizontal. A T-shaped recruitment specialist can run a basic engagement analysis; a T-shaped analytics person can conduct a decent screening interview. The shape is what lets a six-person team cover ten specialisms without ten specialists, and it converts flexibility from a slogan into a staffing property: when demand shifts mid-sprint, T-shaped members flow to the bottleneck instead of waiting for their column of the plan (Natal Dank & Riina Hellström, 2020). Building T-shapes is therefore a deliberate development strategy, pairing, rotation, and the learning sprints of Chapter 10 aimed at each person’s horizontal bar, not a fortunate accident of hiring.

WarningCommon Misconception: A Team of the Best Individuals Is the Best Team

Staffing an agile team by collecting the highest-rated individual performers routinely disappoints, because individual excellence and collective effectiveness are different variables. The evidence reviewed next locates team performance in interaction norms, who speaks, who is safe to dissent, who covers for whom, more than in aggregate talent. Composition sets the ceiling; conditions determine how close the team gets to it.

11.3 What Makes Teams Effective

11.3.1 The Evidence: Safety First

The largest modern inquiry into the question is Google’s Project Aristotle, which studied hundreds of its own teams expecting to find a winning mix of member traits and found none: who was on the team mattered far less than how the team worked together. Five conditions separated its best teams, in descending order: psychological safety, dependability, structure and clarity, meaning, and impact. The first mattered most, and it is the construct Chapter 3 introduced from Amy Edmondson (1999): a shared belief that the team is safe for interpersonal risk, for the question that sounds naive, the dissent that slows the meeting, the admission of error made while the error is still cheap. Edmondson’s own hospital evidence made the mechanism vivid: the best teams did not make fewer mistakes, they surfaced more, and learning followed the surfacing.

For HR teams the finding is doubly consequential. It prescribes their internal design, and it defines their product: if safety, dependability, and clarity are what make teams work, then building those conditions across the organization is a core HR outcome, and an HR team that cannot demonstrate them internally is selling what it does not use.

NoteProject Aristotle’s Five Conditions, as Design Tests for an HR Team
Condition Test the team can apply to itself
Psychological safety In the last retrospective, did anyone admit an error or challenge the lead, and what happened next?
Dependability When a member commits in stand-up, is the default expectation delivery or follow-up chasing?
Structure and clarity Can every member state the sprint goal, their role in it, and the definition of done?
Meaning Can members say why this backlog matters to them, beyond its being assigned?
Impact Does the team see evidence, metrics, user feedback, that its work changes anything?

11.4 The Team’s Operating System

11.4.1 Working Agreements and Decision Rights

Norms that stay implicit are enforced unevenly and discovered through violation. Agile teams write them down as working agreements: a short, team-authored charter covering how work is made visible, feedback expectations, core collaboration hours, and how disagreement gets resolved, revised at retrospectives like any other artifact. The sharpest section is decision rights, and a simple vocabulary prevents the two chronic failures, everything escalated, or everything debated by everyone. Teams can classify decisions as individual (any member, within policy), consultative (a named owner decides after input), or consensus (the few choices, such as the working agreement itself, that need everyone). Darrell K. Rigby et al. (2020) add the structural requirement: the rights the charter claims must actually be delegated by the leaders above it, or the charter is theatre.

11.4.2 Cadence and the Improvement Loop

The team’s rhythm assembles from familiar parts: a visible backlog and board (Chapter 6), a planning and review cycle at sprint or flow cadence (Chapter 5), OKRs at quarterly cadence (Chapter 10). What makes the system self-improving is the loop Chapter 5 called the engine and Toyota called kaizen: the retrospective, held without fail, producing one concrete process change per cycle, owned like any backlog item (Taiichi Ohno, 1988). Continuous improvement in a team is precisely this: not an attitude but a standing appointment with evidence about itself. The iterative mindset, Chapter 2’s growth orientation applied collectively, is sustained by the ritual, and decays without it; teams that skip two retrospectives under delivery pressure rarely hold a third (Carol S. Dweck, 2006).

flowchart TD
    WA["Working agreement<br>and decision rights"] --> SP["Plan:<br>sprint or flow cadence"]
    SP --> EX["Execute:<br>visible board, stand-ups,<br>T-shaped flexing"]
    EX --> RV["Review:<br>users and evidence"]
    RV --> RT["Retrospective:<br>one improvement, owned"]
    RT --> WA
    style WA fill:#e3f2fd,stroke:#1976D2
    style EX fill:#fff8e1,stroke:#F9A825
    style RT fill:#e8f5e9,stroke:#388E3C

TipPractitioner Insight: Protect the Team Boundary

The commonest killer of new agile HR teams is not internal dysfunction but external fragmentation: members allocated 20% to five teams, pulled into escalations, double-booked against functional duties. A person split five ways is a member of nothing. Staff the core team at high, stable allocation, route incoming demand through the backlog rather than around it, and let the team’s product owner, not the loudest stakeholder, order the work. Stability is a precondition for everything this chapter describes; the conditions of effective teams cannot form among people who are only visiting.

11.5 Case Studies

11.5.1 Case Study 1: Google’s Project Aristotle Applied to Itself

Having found that psychological safety, dependability, clarity, meaning, and impact distinguished its effective teams, Google faced the practitioner’s question: can the conditions be built? Its People Operations function, the same evidence-driven culture documented by Laszlo Bock (2015), converted the research into team-level instruments: a survey measuring the five conditions, facilitated conversations in which teams discussed their own results, and concrete practices for leaders, framing work as learning problems, modelling fallibility, inviting input by name, drawn from Edmondson’s research programme (Amy Edmondson, 1999). The significance for this chapter is the loop: an HR function studied teams, turned findings into a product for teams, and iterated it on evidence, agile HR building agile teams.

Discussion Questions:

  1. Why did measuring the five conditions and showing teams their own data change behaviour where exhortation had not?
  2. Which of the five conditions can a team improve unilaterally, and which require its surrounding leadership to change?
  3. Design the retrospective at which a team reviews its safety scores. Who speaks first, and why does it matter?

11.5.2 Case Study 2: ANZ Bank, Scaling Agile Teams and Testing HR

In 2017 the Australian bank ANZ moved roughly 9,000 employees in its Australia division into small, cross-functional, mission-owned squads grouped into tribes, one of the largest such transitions outside Europe and explicitly inspired by ING’s model (Stephen Denning, 2018). The HR consequences arrived immediately and concretely: thousands of role descriptions rewritten around missions rather than functions, selection for the new teams emphasizing collaboration and adaptability alongside technical depth, leaders reassessed for coaching rather than directing, and HR’s own processes, workforce planning, performance, reward, rebuilt to address teams as the unit of value. ANZ’s experience also surfaced the honest costs: the transition consumed enormous change energy, some specialists found no natural squad home, and early sprint theatre, ceremonies without delegated authority, had to be corrected by pushing real decision rights downward.

Discussion Questions:

  1. ANZ selected for collaboration and adaptability when re-staffing squads. What are the risks of over-indexing on these traits, and how do T-shapes address the specialist problem?
  2. Which elements of this chapter’s operating system would you install first in 700 newly formed squads, and why that order?
  3. “Ceremonies without authority” is a recurring scaled-agile failure. Trace its cause using Chapter 3’s delegated-decision-rights argument, and specify the fix.

11.6 Summary

NoteChapter Summary

Agile HR teams are composed small, cross-functional, and outcome-owned, staffed with T-shaped people whose breadth lets the team flex to the bottleneck (Natal Dank & Riina Hellström, 2020; Ken Schwaber & Jeff Sutherland, 2020). Composition, however, only sets the ceiling: the strongest evidence, Google’s Project Aristotle converging with Amy Edmondson (1999), locates effectiveness in conditions, psychological safety above all, then dependability, clarity, meaning, and impact. The team’s operating system makes the conditions durable: written working agreements with explicit, genuinely delegated decision rights (Darrell K. Rigby et al., 2020), a visible cadence of planning, execution, and review, and the retrospective as a standing improvement loop in the kaizen tradition (Taiichi Ohno, 1988). Protected boundaries and stable allocation are preconditions for all of it. Google and ANZ show the conditions built deliberately and the model scaled at industrial size. Chapter 12 completes Part II with the engagement practices and technology platforms that connect agile teams to the wider workforce.

TipKey Terms

Cross-functional team · Two-pizza size · Outcome ownership · T-shaped skills · Psychological safety · Project Aristotle · Dependability · Working agreement · Decision rights · Cadence · Retrospective · Kaizen · Iterative mindset · Stable allocation

Summary

Concept Description
Composition
Small team size Five to nine members, large enough for the skills, small enough to share state without meetings
Cross-functional composition Every skill the outcome requires inside the team, so work finishes without hand-offs
Outcome ownership Organizing around a product or mission with delegated authority, not a shared specialism
T-shaped person Deep in one discipline and capable across neighbours, letting small teams cover many skills
Flexing to the bottleneck T-shaped members moving to wherever work is stuck when demand shifts mid-cycle
Talent-density fallacy The finding that collecting top individual performers does not produce top teams
Conditions
Project Aristotle Google's study locating team effectiveness in interaction conditions, not member traits
Psychological safety The shared belief that the team is safe for questions, dissent, and admitted error
Dependability The norm that a commitment made in stand-up is delivered without chasing
Structure and clarity Every member able to state the goal, their role, and the definition of done
Meaning and impact Members knowing why the work matters and seeing evidence that it changes anything
Operating System
Working agreement A short, team-authored, retrospective-revised charter of norms and expectations
Decision-rights vocabulary Classifying choices as individual, consultative, or consensus to prevent escalation and debate sprawl
Delegation test Checking that rights claimed in the charter are actually released by leaders above
Team cadence The assembled rhythm of backlog, planning, stand-ups, review, and quarterly OKRs
Retrospective discipline One owned process improvement per cycle, held without fail in the kaizen tradition
Iterative mindset Growth orientation practised collectively, sustained by ritual rather than attitude
Stable allocation High, stable membership as the precondition for conditions to form at all
Case Evidence
Google safety instruments Surveys, team conversations, and leader practices turning safety research into an HR product
ANZ squad transition ANZ moving 9,000 people into mission-owned squads and rebuilding HR around teams