Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Do We Need an "Agile Team Lead" Role?
Posted by Mike Bria on Dec 02, 2009
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)?
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
18 agile and lean practices for effective software development governance
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Do We Need an "Agile Team Lead" Role?
by
Liliya Simkhayeva
Posted
Do We Need an "Agile Team Lead" Role?
by
Bob Marshalll
Posted
Something is flawed, and not just one thing.
by
William Martinez
Posted
Re: Something is flawed, and not just one thing.
by
Ilja Preuß
Posted
Re: Something is flawed, and not just one thing.
by
Tobias Mayer
Posted
Self-organised, not led, not coordinated
by
Olaf Lewitz
Posted
Re: Self-organised, not led, not coordinated
by
Alexandra George
Posted
Re: Self-organised, not led, not coordinated
by
Mike Bria
Posted
Re: Self-organised, not led, not coordinated
by
Olaf Lewitz
Posted
Re: Self-organised, not led, not coordinated
by
Tobias Mayer
Posted
Agile must be getting close to jumping the shark
by
Bruce Rennie
Posted
Re: Agile must be getting close to jumping the shark
by
B K
Posted
Do We Need an "Agile Team Lead" Role?
by
Sergio Bogazzi
Posted
Wow
by
Mr Magoo
Posted
-
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. -
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?
@FlowchainSensei -
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.
Cheers.
William Martinez Pomares.
Architect's Thoughts ditto -
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. -
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. -
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. -
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" ... -
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. -
@William.
"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 ;-) -
@Alexandra.
"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. -
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. -
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.
-
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. -
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".
14 comments
Watch Thread Reply