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)?
