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

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …