Are Agile Teams Leaderless?


There is a claim among people that Agile teams are leaderless. The claim can sound reasonable on the surface, with all the talk about self-organizing teams and a lack of defined roles…

But it is wrong for several reasons:

  • Self-organizing does not mean leaderless
  • Agile is not a methodology and does not define the existence or non-existence of a leadership structure
  • Several Agile approaches define leadership roles within the team, typically suggesting that team leaders be elected by their peers
  • Just because a defined role of “Team Leader” or “Project Manager” does not exist within an Agile approach does not mean the team is leaderless
  • The idea of a Servant-Leader in Agile approaches is so accepted that it is regarded as a requirement to be Agile by most Agilists

There are Agile approaches that exist that do define a leadership approach. Some suggest that a team leader for the development team should be chosen by their peers in a vote, and that team leader will work with leadership outside the development team while also serving as a development team member. DSDM suggests this approach for the team leader on the Solution Development Team.

However, when grand sweeping claims such as “Agile teams are leaderless”, Agile may be stated but they often mean Scrum. First of, Agile is not Scrum; I don’t care if some guy you know is a CSM and he states that Agile has Sprints – he’s wrong. Secondly, Scrum has a leadership structure.

From the Scrum guide:

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Books on Leadership

You may be inferring that Scrum development teams are leaderless from this, but it doesn’t say that.

Self-organizing here means someone outside of the development team does not come in and tell them how to do their work. You trust them to do the best job they can, choosing the best and most efficient process to get the work done. If you hired them and don’t trust them to do their job, you may want to revisit your hiring practices.

Self-organizing teams often end up with un-official leaders within the development team, known as emergent leadership. The goal with Scrum though is that the whole team is still accountable and responsible in the eyes of the organization at large. I care what you do, I care that it gets done, I don’t care how you do it (within reason).

I am going to argue also, that they do have some leadership from outside the development team. While no one may be able to tell them HOW to do the work, they still collaborate on WHAT to do during a Sprint. In this way, they are receiving some guidance and direction, exactly what a leader should be doing.

I will also point out that the same Scrum Guide defines the Scrum Master as a servant-leader charged with removing impediments. That gives the Scrum Master some MANAGEMENT (The horrible ‘M’ word) power over the team; which is kind of the opposite of what leaderless means. This arrangement gives the Scrum Master more power than what most people seem to think.

  • If the team cannot decide how to do the work, it is the Scrum Master’s responsibility to guide them (not tell them, but guide them) to a solution.
  • If conflicts become an impediment, the Scrum Master must step in to help resolve the situation; not tell them the answer, but facilitate a solution.
  • If a team member is becoming an impediment to progress, the Scrum Master must do something about it; and if that means the removal of the team member then that is what the Scrum Master must do. Read this for a more in-depth explanation: “Myth 13: The Scrum Master can’t remove people from the Scrum Team”
  • If the team cannot self-organize, the Scrum Master should help facilitate that organization.

Scrum Master according to the Scrum Guide:

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.


Claiming that Agile teams are leaderless is really a misunderstanding of what Agile is and the specifics of Agile approaches. Leaders exist within Agile approaches. They may not be called a “Team Leader” or “Project Manager,” but a servant-leader is still a leader. They may not even have any official power within the organization, but you should empower the team to be leaders and they will most likely self-organize a leadership structure. Failing to self-organize, the Scrum Master (or project manager) should help facilitate a leadership structure with either a formal vote or a collaboration session.

“’Tis but thy name that is my enemy; thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot, nor arm, nor face, nor any other part belonging to a man. oh, be some other name!
What’s in a name? That which we call a rose by any other word would smell as sweet;
So Romeo would, were he not Romeo call’d, retain that dear perfection which he owes without that title. Romeo, doff thy name, and for that name which is no part of thee take all myself.” – Juliet From “Romeo and Juliet” by William Shakespeare




Scrum Guide:

Images from

William Shakespeare: Romeo and Juliet (Act II Scene II)

Categories: Agile, Leadership, Scrum

Tagged as: , ,

2 replies »

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.