Do We Need an "Agile Team Lead" Role?
- Share
-
- |
Read later
My Reading List
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)?
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Do We Need an "Agile Team Lead" Role?
by
Liliya Simkhayeva
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
@FlowchainSensei
Something is flawed, and not just one thing.
by
William Martinez
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.
Cheers.
William Martinez Pomares.
Architect's Thoughts ditto
Self-organised, not led, not coordinated
by
Olaf Lewitz
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
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 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
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ß
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
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
Re: Agile must be getting close to jumping the shark
by
B K
"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
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".
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Hello stranger!
You need to Register an InfoQ account 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