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.
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.