The Agile Executive

Every cure to a problem begins with one obvious step: stop doing the thing that’s causing the problem. No general cure-all or best practice can directly address that first step perfectly for every singe instance. In the world of Agile development, organizations are often plagued with dysfunctionality that must be addressed before Agile methods can achieve the stupendous results those organizations are lusting after.

As I’ve watched people discuss and, more often, argue about Agile over the years, I’ve noticed that these folks often begin their quibbling over this first step: one side of the argument will assume the disfunction in the organization has been – or even can be – taken care of and is, thus, shocked that Agile would not work, while the other is focused on the existence of the disfunction and the impossibility of removing it.

As you can guess, I have no pat answer for how you clean up that problem: that’s the whole point.

It always strikes me that Agile methodologies work very well with functional teams: in fact much of the management side of Agile goes towards identifying (with the goal of getting rid of) dysfunctional team members and processes. Still, you don’t see much on the topic of “Agile firing.”

Other, pre-Agile approaches, however, tend to be the opposite: they’re built around helping an inefficient, dysfunctional base achieve “success” at software delivery. There’s some semantic difference on what “success” means there: for Agile it usually means high quality, for more cynical methodologies it can mean cashing the clients’ check, meeting KPIs, or otherwise CYA’ing instead of “doing the right thing.”

Those are broad generalizations, of course, but I’ve rarely found an agile solution that doesn’t involve making things better rather than dealing with the less than ideal team you’ve been given. Alistair Cockburn‘s work is an interesting exception here where-in he spends quit a bit of time assessing the quality of teams and then trying to match-up methodologies that will work with what you have rather then let you excel with what you wish you had.

The danger here is to think the conclusion is to ask if yourself if Agile will work in your dysfunctional organization. Clearly, if you have a dysfunctional organization, whatever it is you’re currently doing doesn’t work, by definition. But, the trap in that situation is thinking that Agile will help you avoid the difficult task of maturing and getting good enough to even start benefiting from becoming Agile.