Agile Team Lead : Useful New Role?
My pal Abby Fichtner, the HackerChick, blogged today about emerging agile team leadership patterns and practices, as had been reinforced for her by a recent presentation by David Spann. She lists beliefs and behaviors that, according to Spann, when held by whomever actually manages an agile team, tend to help or tend to hurt. These resonated with me strongly.
Premise: It Ain’t Project Management
Meanwhile, coincidentally, I had been in conversations for the last week with stakeholders about how, in an agile transition, old patterns of Project Management are not a good fit. Traditional Project Managers are typically insufficiently team-focused and insufficiently portfolio-focused, while too top-down and imperative. Agile teams and systems have long lifecycles and broadening authority and responsibility that traditional Project Managers cannot typically see. With all due respect to Spann (with whom I think I agree nearly entirely), I would claim that, adaptive or not, neither the adjective “Project” nor the noun “Manager” helps the person trying to lead an agile team. The old culture and terminology are equally misplaced in an emerging agile world.
So, true, the agile community has not had great answers to questions about who leads and manages agile teams, much less how. So, last week, when I was asked by my best Pillar pal and mentor what the main responsibility, the main tools, and the guiding principle of agile team leadership might be, I realized, after some reflection, that I have been baking these in my head for awhile, semi-consciously. David Spann and Abby Fichtner helped me bake them a bit further.
Premise: It Ain’t Tech Leadership
The Agile Team Lead (for lack of a better role term) is not the tech lead. Many teams need formal technical leadership; many teams may grow out of this, into a pattern of entirely emergent tech leadership and architecture. In any case, the tech lead role is not the right role (nor is it typically, as Abby implies, the right skills match or personality-type match) for team leadership overall.
Premise: It Ain’t Scrum Master
As Abby claims at the start of her post, focus on methodology alone, even while there is frequently a temporary place for a certain style of such coaching, is again not the right focus for an Agile Team Lead. This is another focus that is too narrow, and too short. The team should outlive its Scrum Master by years; that may be a measure of a Scrum Master’s skill: the ability to leave the team in a cohesive and self-improving state. No, process coaching is not exactly agile team leadership either.
Look! A Man with Nine Legs! Oh Bloody Hell, He Ran Away
We need something “completely different,” however rare, in our Agile Team Lead. Here are the things I now want:
Overarching Responsibility: Optimizing Flow of Business Value
In whatever ways a team improves: technical, interpersonal, process, practice, attitude, morale — we can measure and express them in how business value is delivered more and more efficiently, easily, steadily, skillfully, and (I’ve seen it) joyfully. The Agile Team Lead can trace all improvements back to how well the team delivers ROI and reduces code asset TCO, and back to how delighted the customer and team both are. The Agile Team Lead is in the business of knocking the customer’s socks off, over and over again.
Four Main Tools
The Agile Team Lead optimizes business value flow mainly with four varieties of tactic:
- Continuous Team Building — this includes all of the soft, fuzzy means Spann lists, whose ends are team cohesion, high ambient trust, high ambient respect, high morale, good humor, equanimity, close interpersonal connection. In Jazz, musicians talk about a band having so much groove that everyone can read everyone else’s mind. Reinforcing that is the Agile Team Lead’s link inward toward the team (bear with my link metaphor here for a few more paragraphs).
- Continuous Planning — for current purposes, I mean by this all of the agile practices and patterns around eliciting, analyzing, scoping, dividing, prioritizing, iterating, planning, testing, tracking, publishing, and delivering. The Agile Team Lead does not perform all of these practices solo, but leads their performance. This is how the Agile Team Lead is held to account by all managers and stakeholders outside the team. This is the outward link from the team to the world.
- Continuous Unblocking — teams continuously need outside help, resources, more team members, fewer team members, and other emergent support that they, as a team, lack the authority to achieve. The Agile Team Lead does the heavy corporate lifting to get these deals swung, to keep the team in steady flow. This is the link from the outside world back to the team.
- Continuous Improvement — The Agile Team Lead guides, without pushing, the zillion varieties of retrospective improvements that the team does own the authority to make. This does include holding the team accountable for owning the ever-changing lists of things to be improved, and concrete improvement proposals and plans. Note that this is not the same as coaching, which may need to happen separately. Teams had better outgrow coaching, while they are never likely to outgrow a need for leadership. These are the links from the team back to itself.
Guiding Principle: Servant Leadership
The leaders most admired in the agile community and software community, as in the world at large, are those who lead by giving and supporting. This is classically the root cause of a graduation from “good” to “great.”
And we are learning that it is simply the most effective variety of leadership and management: collaborative, listening, deeply present, deeply respectful, enthusiastic, inspiring, supportive, celebratory. And certainly trusted and adaptive, as Spann claims.
The Servant Leader attaches identity to the team’s abilities and accomplishments, not just to his or her own. Spann has captured several of the beliefs and concrete behaviors that we can only get from these leaders who lead to serve, not to rule. Indeed, an agile team’s Agile Team Lead must earn the team’s consent to be lead. Mature self-organizing teams eventually outgrow structural, imperative command and control, imposed by fiat.
Doesn’t it seem sometimes that the whole technical world is trying to go collaborative, trust-community, peer-to-peer? Aren’t these same patterns emerging everywhere, in different bits and bobs? Certainly it feels that way to me. Flat is the new hierarchy; village is the new city; conversation is the new document; trust is the new currency; small is the new big.
Thoughts?
That’s my sketch so far: the Agile Team Lead, through the lense of Servant Leadership, uses Continuous Team Building, Continuous Planning, Continuous Unblocking, and Continuous Improvement to optimize how business value flows through the team.
I am still baking this one; your feedback is appreciated.
15 Comments so far
Leave a reply
Wow, thank you for taking these ideas up to the next level!
My first thought is that I’d love to have a leader who is all that you describe here. Can you imagine being on a team where you had such support and momentum towards continuous improvement and learning? This feels like how it SHOULD be and I could imagine such a team to be unstoppable.
My second thought was, “wow, that’s a lot to ask from someone, can one person really do all of that?”
But then, aren’t we asking EVERYONE to take it up a notch or three in agile? Pushing people out of their comfort zones (testers writing code, developers speaking to customers…) to a new level… so why shouldn’t the same be true of our leaders?
Isn’t agile all about us – as individuals – learning and improving along with (or in support of) the software we’re building?
And so, I like this idea… very curious to hear other’s thoughts on the feasibility of this. Is this one person? Is it a team of people in the organization – taking this well beyond just the scope of our software projects, helping the entire organization to continue to grow and learn…?
And, BTW, yes, I do believe these same patterns are emerging everywhere – have been reading Daniel Pink’s A Whole New Mind about how we need to be creative to remain competitive and Keith Sawyer’s Group Genius about how creativity is really a collaborative thing… very exciting to see these ideas emerge!
I’m a big fan of agile leadership; however, I’m not sold on the idea of agile team leads. For teams that are supposed to be self-organizing, I’m having trouble seeing the need for a called-out team lead role. I believe that company leadership and organizational reporting managers need to be servant-leaders and all that, but I need a little more understanding of the need that shouldn’t be filled by team members becoming servant-leaders to each other.
A second thought: I’ve never thought that a team should outgrow its scrummaster any more than it would outgrow its product owner. The scrummaster is not a coach. She is the team facilitator and _is_ actually responsible for protecting the team from distraction and working to remove outside impediments. I don’t think I’m off the reservation on that, am I?
I’m tempted to add career counseling and development in there. That’s one of the things Cem Kaner used to worry about testers being on Agile teams – without a separate test manager, with testers scattered in ones and twos across teams, what gets them together to share ideas, improve their game, and move each of them to their potential?
I’m a big fan of one-on-one’s — back when I was a manager, doing them faithfully was about the only thing I did right. Among the other things they did was allow me to ask “What do you want to be doing in a year? How do you plan to get there? And what can I do to help?” That doesn’t really seem something that naturally happens in a team, without it being someone’s responsibility.
(I’ve been struck by how little training-through-casual-talk happens between teams, even teams that are separated from each other only by a low wall. Seems especially true for product owners.)
Great insight; I plan on moving our organizational thinking in this direction, so it is awesome to see such great discussion/resourcse from you, Abby, and David.
Thanks for the well thought out post!
Paul
Good follow up to Hacker Chick. Loved the “nine legs” comment and agree we are seeking something utterly new and different. In some ways I actually believe the Scrum Master role can be that role. With Scrum there is no focus on methodology, and a Scrum Master is both a servant leader and a transformational change agent. He/she has as much of an outward, organization-facing focus as a team focus. Perhaps more to the former.
So then, I agree with Hacker Chick “…aren’t we asking EVERYONE to take it up a notch or three in agile?”. Yes. The Agile leader that you seek, the one with the team focus will emerge from the team. Different leaders with different focuses. Both operating on the same set of values and principles.
Great article. This is the route we have been going down at Point2 for the last 12 months or so. Good to see that others are going through a similar team leadership transition.
Very eloquent and articulate post. It will be really useful to me when I’m teaching CSM courses and coaching teams, so I hope you don’t mind my borrowing freely.
The one thing that missed for me is the premise that it isn’t the Scrum Master.
With the exception of the “delighting the customer” stuff that you mention, which I put up on the Product Owner side for conceptual convenience, all the rest fits into my mental model of what a Scrum Master is trying to be. Being the Process Owner is but one part of the Scrum Master role, at least the way I have learned it and teach it.
Granted, it’s a tall order. The only reason it isn’t completely absurd to think about is that the Servant Leader model allows the self-organizing team to help with the leadership, too. Emergent leadership, I guess you’d call it.
One other question in my mind: If the team outgrows its ScrumMaster and sends her on her way, what do they do when something changes enough that they drop back to Forming or Storming and need her back?
alan
Thank you for so much thoughtful commentary.
A couple of clarifications.
My premise about Scrum Masters above may be predicated on too little personal data; I may not have enough experience with deeply experienced team leads who self-identify as Scrum Masters. In any case, I dislike the title. I want the team to be led by someone who everyone agrees is the team lead.
Concerning Product Owners: I frequently see Product Owners who work with multiple teams. I want an Agile Team Lead to be dedicated to, and a member of, one team. I would want the Agile Team Lead to represent the way the value flow is optimized from the team perspective. (“For any product our team owns, how well is value flowing?”)
I want the Product Owner to optimize the value flow from the product perspective. (“How well is value flowing for this product, through this team?) I would claim those are not identical concerns, though obviously closely related.
To the point made by several, I also want, whenever it is possible, for the team to decide who the Agile Team Lead is, and for how long. So another premise for me is that the Agile Team Lead is not imposed arbitrarily through command-and-control fiat. Whenever possible, the Agile Team Lead emerges from within the team, for some requisite duration. Maybe forever, maybe for a year, maybe for a Release. Upstream management must, of course, agree that they can trust and work with a particular Agile Team Lead.
Thank you all again; you are helping me think this through better and faster.
@marick I get your concerns. I don’t have good answers there. I want career counseling and coaching to happen; I don’t know if my proposed notion of Agile Team Lead above is the right role/person for that.
I have been recently working in organizations where team members “structurally” report to some Dev manager who is responsible (for better or for worse) for the career counseling (and raises and hiring and firing) for several people across several teams. In such a place, the Agile Team Lead might be partly off that hook, though I would say not entirely. An Agile Team Lead would certainly own finding a solution for blatantly disruptive personal behaviors showing up on the team, for example.
Great post!
A couple of things struck me that might be food for thought:
– Teams may outgrow a full-time coach, but some coaching skills will always be useful on the team. People forget and need to be reminded of basics. New team members join. Etc.
– I like the idea of having an actual PM assigned to a project if the organization has somewhat heavy requirements around status reporting. There are many companies that say “we’re agile”, but impose onerous formal requirements for reporting status.
- On career counseling… I’m not sure that it is as critical with agile developers. I haven’t really baked out the reasons why but I’ll let that percolate a bit & probably blog about it myself. :c)
I wonder how much the need for this varies based on team composition. I wonder how the responses are impacted given their individual experiences working on teams that are particularly well-run and strong, versus teams that are struggling or filled with followers?
I have not seen very many good, strong, self-organizing, as-close-to-ideal-as-possible teams, personally. I have seen several teams where there are more natural followers than leaders, and from those teams, the natural leaders emerge. I have seen teams with people on them who are just not very motivated to do better — these people are more in need of some leadership.
On a team with mostly strong, ambitious, motivated people who are working well together and interested in continuous improvement already, would this role be needed? Gut tells me no …
On the rest of the teams, I believe that people already emerge naturally as “agile team leads”, though perhaps even those don’t embody all of these traits.
I feel like for the most part the qualities you described should be *ideally* ingrained into every team member, making the need to embody them in one person unnecessary.
It feels like this particular role would be one that I would hope could be considered as a “training wheels” role, and with time all members of the team would take on the qualities. It answers a (team) question for me of “We know how we *should* be, but we are not. What do we until we are?”
[...] See Patrick Wilson Welsh’s response: Agile Team Lead : Useful New Role? which takes this idea to the next level, and join in the [...]
Good follow up to Hacker Chick. Loved the “nine legs” comment and agree we are seeking something utterly new and different. In some ways I actually believe the Scrum Master role can be that role. With Scrum there is no focus on methodology, and a Scrum Master is both a servant leader and a transformational change agent. He/she has as much of an outward, organization-facing focus as a team focus. Perhaps more to the former.
So then, I agree with Hacker Chick “…aren’t we asking EVERYONE to take it up a notch or three in agile?”. Yes. The Agile leader that you seek, the one with the team focus will emerge from the team. Different leaders with different focuses. Both operating on the same set of values and principles.