I think this kind of thinking brings us closer to understanding the kind of “leadership” that an Agile team needs, and does nothing to detract from the internal leadership shown by experience and/or committed folk within the team (leading by example or leading from within). I think there are differences between what you’re talking about and typical scrum masters although I haven’t quite found the way to articulate that – I suspect it lies in the areas of Leadership, Risk Reduction and (sometimes) continuous improvement sections you’ve identified. What you’ve described matches what I would aspire to be (as a current “Manager” of Agile teams). I’m off to think more about that… Thanks.

1. “Identifies, gathers, and acts tactically on meaningful performance/progress metrics”

Do you envision this reaching well into the Product Owner realm?

For example, would the Agile Team Leader define the Customer Development processes to illuminate metrics that would steer the Product Owner into a more iterative feature cycle? Unfortunately I’ve witnessed traditional Product Managers thrust into the Product Owner role, and even after training cling to 20th century metrics. I find it interesting that this role may be empowered to help correct that scenario.

2. “There can be no Agile Team Lead designated FOR a team that does not know, admire, trust, respect, and like that person.”

What about the teams that lack that player, and therefore have a consultant dropped into the mix?

In the past I’ve had success as an embedded scrum master / coach dropped into a team, but I needed to establish trust asap. This role seems to be similar except dialed up to 11.

thanks,
-David

Also, I’d question the value of naming the role as a lead: this has implicit connotations of a command structure within the team.

Let the discussion continue. Thank you all again.

Any team member who feels they have no responsibility to the customer or the organization they work for should, frankly, be laid off. The is no room for that kind of lethargy in an Agile team. We seek greatness, surely?

First, I agree and would underscore your point that this is an awful lot of skill and responsibility for any single person to wield. I fear that staffing this role would suffer the same issues that staffing a Product Owner so often does: almost no one has the skill and knowledge to pull it off, and if anyone does, they either already work somewhere else, already work for you, or aren’t available full-time because they consult at multiple organizations for spectacular hourly rates. Best bet is if they already work for you, they can grow into the new position. Whatever manager is in charge of hiring the Agile Team Lead had better provide a lot of political cover in that person’s early days.

Second, I see a real dichotomy in the agile space, arising from the conflict between sheltering the team and fostering communication with stakeholders. Agilists like to let the team crank out working product and to get their minds in context and keep them there; that means blocking would-be interruptions such as stakeholder questions. We also like to have a sort of open-door policy where the communication lines between team and stakeholders are wide open. These two ideals can easily conflict: I’ve seen where frequent stakeholder questions and interruptions disrupt the developers a lot. I’ve also seen where problems get missed when someone wasn’t in a discussion—because they wanted to stay focused on their code instead. If I read you right, you’re putting your stake down in the “shelter the team” camp, with the Agile Team Lead providing different sets of data to the team and outside the team. I’m still not sure which side of that divide I would set myself, but it depends a lot on the “agile maturity” of the stakeholders—the more they understand how the team works, the less the team needs to be protected from them. Also, the more consistently the team delivers real, working software every iteration, the less the stakeholders feel inclined to ask question mid-sprint.

Third, I agree with your assertion that most agile adoptions leave a lot of concerns unmet, but I hesitate to solve it by piling even more responsibility on a single person. Even the highest-performing teams I’ve been on constantly felt they were missing the mark badly in one area or more, even while they recognized their overall high speed and loved working the way they did. I tend to attribute that persistent deficiency-perception to the fact the doing agile really well is _really_hard_, and that anyone who does it moderately well has the self-awareness to know how much better they could still be. A lot of your bullet points embody things that need to come from the whole team having a consistent attitude; even a great leader can’t completely make up for players who just won’t go with those ideals—short of firing and replacing all such players. Then again, maybe that’s exactly what you’re getting at.

I would be interested to hear what beefs the “you’re smoking crack” critics have with your proposal. My differences may arise mostly from never having been on a team where one person really played that role—and I expect I’m not alone in that non-experience. Some case-studies might be very helpful.

One thing I do realize when reading this post: the team in my past that came closest to having an Agile Team Lead person was also the highest-performing and most personally satisfying team of my career. That really gives me something to think about, and lends credence to the idea that you are onto something very useful. I look forward to the ongoing discussion.

I’d like to understand more about where you think the new Agile Team role that differs from the ScrumMaster role. It seems that the responsibilities you’ve given here could be handled by the ScrumMaster, but I think you’re trying to get to something bigger – would like to understand that.

Also, your “freedom to fail” is awesome and reminds me of Jared Spool’s keynote at Agile 2009. He said that when his company researched all the WILDLY SUCCESSFUL products (iPhone, Netflix, etc.) the common point that they had, that nobody else had, were these 3 questions:

1) Vision: Can everyone on the team describe the experience of using your design 5 years from now?

2) Feedback: In the last 6 weeks, have you spent more than 2 hours watching someone use your or a competitor’s design?

3) Culture: In the last 6 weeks, have you rewarded a teammember for creating a major design failure?

(okay, it was that last question I was thinking of – but if we know all 3 are commonalities of wildly successful firms, what can we do to incorporate these traits into our teams?)