malvasia bianca

When I first saw Brian Marick’s complaint about the prevalence of the term “leadership” at Agile 2006, my first reaction was “hmm, that doesn’t sound so good, and here I am being part of the problem.” After thinking about it a bit more, though, the Christopher Avery talk that I blogged about doesn’t sound like the sort of thing Brian Marick is bothered by – that was really about responsibility, a concept which is equally applicable to all levels of the organization.

Still, I was pretty sure he was onto something. (Side note – where did I read an article recently complaining (intelligently) about bossism?) But then, a couple of days later, I saw Brian Marick on a stage helping present the Gordon Pask award. So it would seem that my understanding of the “Great Man theory” and his understanding are somewhat different. I guess he’s more focusing on the ills of executive leadership than on other forms of leadership? The team leads the Scrum Master but the organizer leads the XP day participants? Seems a bit odd to me.

This seems to be the focus of his post:

We know how to do software better. It’s the executive’s job to support us in doing that—to clear obstacles out of the way of our practice—and not to lead us. We already know where to go. We know how to do our job. We need to be assisted, not led.

On the one hand, I sympathize with that a lot. I’ve had one notable experience with an executive pushing his pet theories on a development team, and it’s one that I hope not to repeat. I’m a fan of the notion that you should move decisions to the lowest responsible level. And it’s unquestionably the case that people who are doing something out of internal motiviation will work at it much more effectively than people who are doing it out of external motivation.

On the other hand, I can’t uncritically accept the statement “We know how to do software better”. Another past experience that I’d like to avoid in the future involved a project where decisions were supposed to be made relatively communally, yet where dysfunctions seemed to me to hurt the effectiveness of the team’s operation; while I can imagine other solutions to that problem, I’m sure that an effective executive would have stepped in and resolved the issues much more quickly. To be sure, an ineffective executive could well have exacerbated the problem, but I won’t argue that that group as a whole “[knew] how to do software better.”

And just what is the better way that we allegedly know how to do software, anyways? Given the context, I assume it’s agile in some form; my experience is that many/most programmers aren’t particularly well steeped in agile ways of thought, and that, when exposed to those ways of thought, most programmers find some areas they agree with, some areas they are suspicious of, and have good reasons for their suspicions. Also, if we know how to do software better, did we also know how to do software better 10 years ago? Were our answers the same then? Will our answers be the same 10 years from now? Are we sure that teams will always come to those new insights before executives? I’m not. This stuff is hard; I can use all the help I can get.

On the third hand, just who is the “we” who know how to do software better? Agile practices bring in a large number of stakeholders. In particular, even if we want to move decisions to the stakeholders most directly affected by those decisions, a key stakeholder is the gold owner, who is likely an executive. I can understand arguments that, say, the gold owner shouldn’t have much to say about the details of your refactoring strategies. But I think the gold owner might well have a lot to say about the composition, frequency, and quality of your deliverables, or about the reliability of your estimates, and hence has every right to feel strongly about, say, the planning game, frequent releases, and the quality of your test plan.

The most interesting examples I know of of companies that have productively moved decisions to lower levels are Toyota and Semco. My understanding is that, in both cases, executive leadership played a strong role. I won’t say that it was the only factor, but surely we can learn a lesson from that? One of the key agile tenets is the importance of communication; we should embrace productive communication with executives, accept them as potential active resources for change, not limit our vision of their job to simply be “to clear obstacles out of the way of our practice”.

 

After writing the above, now I’m starting to understand why some people say that retrospectives are the single most important agile practice. Communication is key, getting people at all levels to think about how we could best do our work is crucial. And I can imagine how increasing the openness of conversations could potentially have helped greatly with some areas where we’ve functioned at less than peak effectiveness over the last few years. I’m looking forward to our team retrospective on Monday.