Do We Need an "Agile Team Lead" Role?

| by Mike Bria Follow 0 Followers on Dec 02, 2009. Estimated reading time: 2 minutes |

Patrick Wilson-Welsh, Chris Beale, Gary Baker, John Huston, Daryl Kulak, and others are attempting to popularize the idea of a new role, the "Agile Team Lead", to replace many of the existing leadership roles found in and around agile teams.

In Wilson-Welsh's words:

We are deliberately attempting to erase old agile team management role and responsibility labels, like Scrum Master and Project Manager, which we increasingly believe to be fundamentally broken. We find the controversy around this topic to be perfectly matched to the stakes involved for the enterprise: our current patchwork of agile team management and project management and product ownership and process improvement management consists of more holes than cheese.
Love it or hate it, we need a paradigm shift around agile team leadership. We need that leadership to be better consolidated, better focused, better defined, and better matched to the dialectic between internal team needs and external stakeholder needs. We need one person who is held accountable the extent to which an agile team’s authority and responsibility are, in fact, congruent.

This person, they propose, being the "Agile Team Lead". Wilson-Welsh goes on to present a draft outline of what would be expected from such a role. A summarized look at this (already summarized) draft includes the following 5 categories of responsibility:

  • Continuous Leadership
    Understanding the team's place in the organization's goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a "safe container" for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.
  • Continuous Planning
    Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain "big and visible", manages metrics, making "the plan the bad guy" (as opposed to the people), and ensuring the "plan changes with demand/supply".
  • Continuous Execution
    "Monitoring/managing team velocity/throughput", securing resources, removing and escalating blockages. Ultimately, "keeping flow, momentum and focus in the team".
  • Continuous Risk Reduction
    Identifying risks and making their "potential impacts big and visible to the right people", ensuring risk reduction occurs, and quantifying risk management effectiveness.
  • Continuous Improvement (Agile Coaching)
    Driving the "improvement of the overall Definition of Done", sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.

Early feedback is mixed. Abby Fichtner (aka, "The Hacker Chick") and John McFadyen both support Wilson-Welsh's thoughts, but ask how the "Agile Team Leader" role differs from that of a "Scrum Master". Abbey further went on to note how the "freedom to fail" undertone of the responsibilities described reminded her of Jared Spool's Agile 2009 keynote in which he outlined 3 characteristics common to many "wildly successful" projects.

Tobias Mayer objected to these responsibilities being relegated to select people, asserting that "every team member needs to" embody the qualities Wilson-Welsh describes. According to Mayer:

Creating a “role” of team lead is the beginning of a slippery slope back to command and control, It is a cop-out, an excuse for not facing the real challenge of nurturing a leader-full team.

What do you think? Would such a role definition be helpful? If so, how could this draft definition be improved? Or, is the role a redundancy, even maybe a flat-out bad idea (as Mayer proposes)?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Do We Need an "Agile Team Lead" Role? by Liliya Simkhayeva

I think it would be safer to call the role 'Team Coordinator' rather than 'Team Lead'. This way the 'leadership' aspect will remain the responsibility of each member of the agile team.
The coordinator will simply help the team work together effectively and in line with the common goal.

Do We Need an "Agile Team Lead" Role? by Bob Marshalll

I believe the idea of "Team" is easily as flawed, broken and dysfunctional as "Project", "Project Manager" and "Scrum Master". Let's move away from "team" shall we, and try to focus on whole-systems-thinking?


Something is flawed, and not just one thing. by William Martinez

Ok, let's see:
Flaw #1. Leadership=command and control? NO. A leader is the person you seek for advice, that resolves issues, that you take as an example, that inspires and you follow because that person is the one you want to follow, not imposed. So, a leader is not the one that will dictated each line of code written to all the others. That is non-sense. AND, leadership may not be a role, but a natural competence.

Flaw #2. The self-organizing Team is an only-leaders team? NO. A team full of natural leaders is a mess. A self-organizing team does not mean chaos, or everyone doing whatever they want. Is a team that in democracy sets a line of behavior, takes cares of their issues, almost think as one person. That team may have one or two leaders in it.

Flaw #3. Anyone not coding is useless? NO. Developing is not just writing code in the current language. Development is a complex process of defining, creating, testing, matching, recording data for improvement, adjust over time, tackle the changes, solving team issues and people issues. It needs a full team with one or several roles in it (depending on the project type and size). So, there may be someone that is not proficient in the current language, but is full or work solving lots of other problems that are not exactly coding ones.

Methodology wise, roles should be dynamic!
They depend on the people you have at hand, the project, and the development requirements!.
For instance, a maintenance project may require a person that knows the old code, and that person plays an special role. A project with almost no defined requirements may need lots of communication with the client and other stakeholders, and may require one person almost full time in that communication process.


William Martinez Pomares.
Architect's Thoughts ditto

Self-organised, not led, not coordinated by Olaf Lewitz

Defining a role sends a message. Define a leader role, and people will follow. Define a coordinator role, and people will start doing what she says, "because she said so". If you want a team to self-organise, give them a vision and a coach.
My answer is no. IMO "agile team lead" is a contradiction in terms, aka oxymoron.

Re: Self-organised, not led, not coordinated by Alexandra George

I hear an opinion frequently from the team that managers add no value and that they get in the way of the team doing work, however experience tells me time and time again a team without management, no matter how much they think they are self-organising, is more prone to failure. The failures I see are in communicating outside of their team. They may be perfect within their project community but how many software projects exist in a vacuum? None that I have been on.

Good stakeholder relationships = good direction form the sponsor, good direction from the sponsor = a project with great purpose and clear goals and that = increased chance of a successful project.

Teams that are inwardly focused and don’t care about “up and out” communication, can easily go off track or fizzle out in relevance. How many teams of pure DEV/QA/BA members would be in the face of a project sponsor?

I also think “Agile” defining it’s own terms for Project Manager other than Project Manager can alienate "Agile" from the rest of the software development world, which does it no favors in increasing uptake and becoming mainstream.

Re: Self-organised, not led, not coordinated by Mike Bria

I'm with you on the first three paragraphs. But...
I also think “Agile” defining it’s own terms for Project Manager other than Project Manager can alienate "Agile" from the rest of the software development world, which does it no favors in increasing uptake and becoming mainstream.

I'm not so sure "Agile" is as concerned with becoming the popular kid on the block (ie "increasing uptake and becoming mainstream") as it is with being understood, applicable, and effective. That's not to say "it" desires to re-label things or buck the status quo wherever or whenever, but "it" will if that's what it takes.

At least my $.02, anyway.

Re: Self-organised, not led, not coordinated by Olaf Lewitz

You are right in what you say, but it doesn't support the case for a new role named "Agile Team Lead". If you see the need of a "Agile Team External Communicator" role (which is a bad name, just making a point), you're starting a different discussion.

Every team needs to find a balance between internal cohesion and external coupling (you probably heard that sw architecture often mirrors team structures, this is why). If they only nurture their internal culture, they lose their jobs, if they only nurture external relationships, you lose the team. Some teams find that balance, some need help. That entirely depends on the people.

A product owner or scrum master might just excel in this external communication, or might empower the team to find that balance. If not, you might need someone else - and that, imo, is exactly what a coach is for.

Regarding your critique of new terms: I think and know from experience that to change organisations, you need to change the language and the metaphors that frame their views and culture. Humans work that way.

So, to give my honest and plain opinion, "Project Manager" and other "non-agile" roles need to go. People occupying them need to be given time, trust and support to find new responsibilities in a changed organisation. If you want to make agile (or lean, or continuous improvement) work in the long run, this is a step you need to take. You need to reframe the view on the jobs, and for this you need to change the names. This might even be - at some point in the future - the fate that awaits the "ScrumMaster" ...

Re: Something is flawed, and not just one thing. by Ilja Preuß

Uh, I agree that those three statements would be wrong. And I don't see anyone arguing that way.

Yes, leadership != command and control. A leadership *role*, though, is a slippery slope towards c&c.

Yes, you wouldn't want a team full of "natural leaders" (whatever that is, but it sounds to me like a lack of diversity). That's different from a leaderful team, though, where every team member might temporarily take leadership, as needed.

Don't know at all where the "anyone not coding is useless" is coming from. Perhaps I didn't read carefully enough.

Re: Something is flawed, and not just one thing. by Tobias Mayer

"Flaw #1. Leadership=command and control" where does anyone say that?
"Flaw #2. The self-organizing Team is an only-leaders team" where does anyone say that?
"Flaw #3. Anyone not coding is useless" and where does anyone say that?
It seems you are reading things into this discussion that are not there. Or perhaps accidentally commenting on a different discussion... maybe you were task-switching at the time ;-)

Re: Self-organised, not led, not coordinated by Tobias Mayer

"I also think “Agile” defining it’s own terms for Project Manager other than Project Manager can alienate "Agile" from the rest of the software development world"

Yes! and Hooray! The sooner the better. We make our own party, and it will be so fantastic that all those old school dudes will finally give up and go home, or join us.

Agile must be getting close to jumping the shark by Bruce Rennie

I'm no spring chicken to agile, having worked on teams using XP and Scrum for 9 years now. Lately it feels as if the agile world is turning into a soap opera. There just seems to be a lot of drama around things I just can get all that worked up about.

What happened to the basic agile rules of "adapt"? What makes people think that a new "Agile Team Lead" role is going to have any fewer problems than the Scrum Master role? What makes anyone think they can define a set of rules/roles that is going to be bulletproof in the first place?

Haven't we learned yet that the basic Scrum rules are a just a starting point?

Sorry, I'm not getting this "problem" at all.

Do We Need an "Agile Team Lead" Role? by Sergio Bogazzi

I tend to agree with Tobias. Peter Drucker said that as knowledge workers we are executives. In other words, all members of an agile team are responsible for deciding on 'doing the right things', in addition to 'doing things right'. If you agree, then the biggest investment a executive can make is their time. I would add, some of the comments seem to be confusing leadership with management.

Re: Agile must be getting close to jumping the shark by B K

I totally agree. Past few month I haven't seen any new topic with respect to Scrum and Agile, whether it's infoq, slashdot or even linked-in q&a in Scrum/Agile groups. I have a feeling that again too many managers are involved in being Scrum Masters/Product Owners who in reality do not understand Agile. Agile is a mindset - it simply states 'no bs, keep it simple and above all - communicate'. I've noticed most people have problem with the latter and so they tend to invent roles, rules, etc. Agile is about culture and creating new work cultures from the existing team. People should communicate, learn from each other. The biggest problem is not SCRUM, rules and roles but people. Let's be honest the Southpark way - there are no stupid questions, just stupid people. Lately I see all the same questions over and over and battles over how it should be done. If you're asking how it should be done looking for rules and not inspiration than you don't get Agile at all. Your whole sorrounding is specific to your case and only you can make it Agile. SCRUM provides guidelines, tips - not rules. You may have proper Agile without charts, user stories, etc. - these things do not constitute Agile, people do.

"We need one person who is held accountable the extent to which an agile team’s authority and responsibility are, in fact, congruent."
No, we don't need one person. Yes, we need leadership.

Wow by Mr Magoo

So many generalizations, so little time...

It really does depend on the organisation and the team in question. It may even be that the role's job description might be to make itself irrelevant. (ignoring the conflict of interest that creates)
Some teams will not need one, some will. Some will need it when they are starting out, especially if the scrum master role (absolutely despise that term BTW - talk about sending C&C messages?!) is not being filled that well or at all. Talking about all teams as gross generalisations is just folly. It is great for a theory when you can just dismiss any failures as "not doing it right".

In short: I really think that these sort of discussions (and I have read many) totally ignore some of the practical realities out there and just plain old human variance.

e.g. It is also the case that many times a "scrum master" IS one of the team. In a worse case the scrum master is the PM or other manager and really does not know what the team need. They will naturally become the "team lead" if there is not a concerted effort to the contrary.
e.g. Sometimes the most senior developer/architect will naturally fill that role - regardless of what the theory dictates. This could just be a pure knowledge/experience thing rather than C&C.

This quite often works and I would argue that the above is NOTHING NEW practically, just new in terms of the theory itself.

As soon as we start treating concepts such as this as "must or must not do" then we are falling for an age old fallacy. To the detriment of another bunch of teams "not doing it right".

Re: Do We Need an "Agile Team Lead" Role? by VamsiKrishna D Reddy

I agree with Liliya Simkhayeva - Every one will responsible and take ownership for their work& deliverables - Team Coordinator will only help and make team effectively work to deliver in timelines.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

15 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you