Skip to main content

Schrödinger's Agile Leader

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 BA, a Dev, or a 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, 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 has joined ThoughtWorks this month, has this helpful list of things agile "executives" can do:
  • aligning agile transformation efforts to business strategy
  • helping 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.

Comments

  1. Its interesting that you write about the attributes of an "agile leader" and I'm thinking whats all about agile in here. Ain't all leaders suppose to "cleave through ambiguity and complexity"? Ain't leaders supposed to lead with well grounded thoughts and follow up action? Gandhi and John Adams were just awesome leaders - agile or not :)

    As for Scrum, it has its limitations on how the roles are defined.In a start-up organization practicing agile methodologies, Product Owners are leaders.

    ReplyDelete
  2. I actually enjoyed reading through this posting.Many thanks.


    Agile Training

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica