Elena Yatzeck, Pragmatic Agilist and the paradox of Agile Leaders… necessary to sustain a culture that fosters disruption
Curated by Helena Herrero L.
The “agile team leader” seems at first glance to be a sort of Schrödinger’s cat: if a project team is self-governing, then who is leading it? If there’s a leader, is it self-governing? Is everyone a leader? Is “the team” a leader? What happens to individual responsibility and career development, and who watches over it? Who makes the decisions? What does an agile executive look like? As Martin Proulx captures the issue in the title of his excellent August Analytical-Mind blog posting, “I don’t feel so good, I’m a people manager in an Agile organization.” It’s interesting to think about.
One way to break this question down is to recap some standard and helpful distinctions in vocabulary. In the growing field of “leadership training,” it has become well understood that a “manager” is not the same as a “leader.” See for example this ChangingMinds.org blog entry. As managers aspire to become executives, they are sometimes prepared for this increased responsibility by undergoing a specific leadership training which talks about three total roles:
- Doer: gets things done
- Manager: ensures things get done right
- Leader: ensures the right things get done
If we apply these terms to the problem of an “agile leader,” within the context of an “agile team,” we can see immediately that on an agile team, all team members are asked to play the combined roles of “doer” and “manager” for the team, and that being the “leader” is a different role. In Scrum, the “Scrum Master” would to some degree ensure that things get done correctly, but a Scrum Master would not typically tell a Business A (BA), a Developer (Dev), or a Quality Assurance (QA) how to do his or her job, but rather help be the conscience of the team in terms of making sure agreed upon Scrum practices were being followed.
In Scrum, the person who decides “what” the software should do would be the Product Owner (PO), and the team might take guidance on “how” to implement the software from a technical lead or software architect. So on the face of it, the Product Owner and Tech Lead could be considered the leaders. But hold that thought for a second.
A final, helpful piece of vocabulary is the concept of the “Executive.” Jim Highsmith, who I’m excited to say joined ThoughtWorks this month, has this helpful list of things agile “executives” can do:
- aligning agile transformation efforts to business strategy
- supporting teams understand and deliver on business, product, and project objectives
- creating an agile performance management system
- facilitating a decentralized, empowered, collaborative workplace
- fostering an adaptable product line and product architecture
- creating an agile proficiency framework
- creating both proactive and reactive organizational adaptation processes
- understanding the agile development process
- creating guidelines, training; and support for agile processes, practices, and tools.
But are we there yet? I think not. On the ground, knowing the goals, as the PO and the tech lead do for a Scrum team, or even knowing what the strategic goals should be, as Highsmith’s agile executive does, is not the same as leadership either.
I habitually turn to Joe Vranich for advice when I am in need of wisdom, and when I talked with him yesterday, he passed along this quotation from Peter Drucker to me:
“Only three things happen naturally in organizations: friction, confusion, and under-performance. Everything else requires leadership.”
Drucker’s name doesn’t come up frequently in the agile theory texts I’ve been reading lately, for a number of reasons (see this lovely Business Week eulogy from 2005), but doesn’t this quotation really capture the essence of the problem? A leader addresses sources of friction, confusion, and under-performance and does something about them. So coming full circle, in an August 24 post on the Cutter site, Highsmith, too, talks about how leadership comes down to having the ability to reduce ambiguous situations to their essentials:
Agile leaders have the ability to cleave through this ambiguity, to focus on a decision when everyone else is floundering, to clarify direction when everyone else sees confusion. This requires an ample supply of thought and analysis, but probably an even greater supply of guts.
In the end, I posit, leadership is a fundamentally human excellence. It is not something which can be captured on a card wall or a burn-up, or guaranteed through daily 15-minute stand-ups. Leadership is a human trait, and if there’s something like a prototypical “Agile leader” we want to be nurturing, that person is going to be deft at working with that other prototypical Schrödinger’s cat, the “Agile enterprise” which never quite settles upon whether to be a philosophy or a set of techniques.