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.

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…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …