Leading self-managing teams

Agile frameworks give teams the right to decide how to do their work. That changes what leadership looks like. The project manager or agile lead no longer plans every task and checks every result; instead, they create the conditions in which a team can plan, decide and improve for itself. PMP-120 covered team development, motivation and conflict in general terms. This lesson applies those ideas to agile teams, where the exam repeatedly rewards one pattern: serve the team, protect its focus, remove obstacles and let it decide.

Servant leadership

Robert Greenleaf coined the term servant leadership in 1970 to describe leaders whose first aim is to serve the people they lead, helping them grow and perform, rather than to accumulate power. In agile contexts, servant leaders focus on purpose (making sure everyone understands why the work matters), people (creating an environment where they can do their best work) and process (helping the team find and improve a way of working). They lead by asking questions, listening, coaching and removing barriers.

Servant leadership is not passivity. A servant leader still sets direction, holds the team to its commitments and makes hard calls when needed, such as escalating a vendor problem or raising a performance concern privately. The difference is the default: support and enable first, direct only when the situation requires it.

Self-organizing and self-managing teams

The Manifesto's principles speak of self-organizing teams; the 2020 Scrum Guide uses self-managing, meaning the team decides who does what, when and how. Self-management has limits. The team works within boundaries set by the organization: the product goal, the budget, legal and safety rules, the definition of done and the organization's policies. Inside those boundaries, it has real authority. Leaders help by making the boundaries clear, because a team unsure of what it is allowed to decide will either freeze or overreach.

One practical tool for this is delegation poker, from Jurgen Appelo's Management 3.0, which describes seven levels of delegation: tell (the leader decides and announces), sell (decides and explains), consult (asks for input, then decides), agree (decides together), advise (offers input, the team decides), inquire (the team decides and informs) and delegate (the team decides without needing to inform). Agreeing the level for common decisions removes a lot of friction.

Team charters and working agreements

A team charter, sometimes called a working agreement or social contract, records how the team intends to work together. It is created by the team, not handed to it. Typical contents include the team's purpose and values, core working hours and communication norms, how decisions are made, the definition of done, how conflict is handled and how the team will treat one another. Because the Compass app team combined library staff and a contracted firm, its charter also covered how to raise concerns across the two organizations.

Decision techniques often named in exam questions include fist of five (each person shows zero to five fingers to indicate support; anyone showing one or two explains their concern), Roman voting (thumbs up, sideways or down) and dot voting (distributing a set number of dots among options). They are quick ways to check consensus and surface objections, not substitutes for discussion.

Psychological safety

Amy Edmondson defines psychological safety as a shared belief that the team is safe for interpersonal risk-taking: that people will not be embarrassed or punished for speaking up with ideas, questions, concerns or mistakes. Research at Google and elsewhere has found it to be one of the strongest predictors of team effectiveness, and the second edition of PMI's Agile Practice Guide treats it as essential. Without it, transparency fails: problems are hidden, retrospectives become polite, and estimates are padded.

Leaders build psychological safety by framing work as learning, admitting their own mistakes, asking for input and responding constructively when someone raises a problem. Jordan noticed that Tess, the newest developer, never spoke at retrospectives. He switched to a format where everyone first writes notes silently, and invited her privately to share an accessibility concern she had mentioned to him. Her point, that the colour contrast on the hold status labels failed the standard, became the team's top improvement.

Conflict on agile teams

Healthy conflict about ideas is essential; agile teams that never disagree are usually avoiding issues. Speed Leas's levels of conflict, often used in agile coaching, help a leader judge how to respond. At level 1 (a problem to solve), people share information and look for solutions. At level 2 (disagreement), self-protection creeps in. At level 3 (contest), people take sides and winning matters. At level 4 (crusade), the aim is to protect one's group or remove the other. At level 5 (world war), the aim is to destroy. Teams usually resolve levels 1 and 2 themselves; levels 3 and above need a facilitator and possibly escalation.

In sprint 8, Luc and Mei argued sharply about whether to cache catalogue data in the app. By the second day it had become a contest, with other developers taking sides. Jordan facilitated a short session: what problem were they each trying to solve? Luc wanted speed for patrons; Mei worried about showing stale availability. They agreed a one-day experiment caching only search results for five minutes, with availability always fetched live. The experiment settled the question with data.

Supporting the team from outside

Many of the obstacles agile teams face come from outside the team: slow approvals, vendors, shared environments, conflicting demands from managers, or policies designed for predictive work. Removing these impediments is one of the most valuable things an agile lead or project manager can do, and often requires influence rather than authority. The Compass project manager negotiated a faster security review with the library's IT security office, arranged for the catalogue vendor to provide a test environment and persuaded finance to accept monthly invoices based on sprint reports instead of milestone certificates.

Motivation also benefits from the right environment. Daniel Pink's summary of research on knowledge work highlights autonomy (control over how one works), mastery (the chance to get better at something that matters) and purpose (a connection to something bigger). Agile teams have autonomy built in; leaders can add mastery through learning time and pairing, and purpose by connecting the team with the people who benefit, such as inviting patrons to sprint reviews.

Distributed and hybrid teams

Agile principles prefer face-to-face conversation, but many teams are distributed. Effective distributed teams invest in a shared digital board, video by default for important conversations, overlapping core hours, a working agreement for communication and occasional in-person time for building relationships. Leaders watch for people being left out because they are remote, and make sure decisions are recorded where everyone can see them. Generative AI tools, which the new Agile Practice Guide discusses in each chapter, can help summarize discussions or draft stories, but teams should agree where they are used, check their outputs and protect patron data.

Coaching stances

Agile leads move between stances depending on what the team needs. When the team lacks knowledge, the lead may teach, for example explaining how to split stories. When the team has the knowledge but is stuck, the lead coaches with questions that help it find its own answer. When the team needs to reach a decision, the lead facilitates, keeping the conversation fair and on time without taking a side. When a team member needs longer-term development, the lead mentors. Knowing which stance a situation calls for, and moving out of teaching and into coaching as the team matures, is a mark of a skilled agile leader. Early in the Compass app work, Jordan spent much of his time teaching Scrum to library staff; by release 1, he mostly facilitated and coached, and the team ran its own retrospectives.