To Say Agile, Or Not to Say Agile… That is the Question
This is my site Written by Alora on May 6, 2009 – 7:41 am

Telephone GameI had an interesting conversation yesterday after I gave a presentation. I was talking about the necessary functions — particularly when it comes to communications, documentation, change management and entry/exit criteria — of project management in an Agile development process.

The “interesting” conversation I had afterward was because one of the attendees (in a private conversation) busted me for never once using the word “Agile” in my presentation. I’ve told him that it was deliberate, and here’s why:

What’s in a Name?

“Agile Development” is bullshit in and of itself. I don’t like or use this phrase because it’s a dangerous misnomer. As I’ve written about before, either your entire organization is going to be “Agile” or none of it is. You can’t just have “Agile Development” and expect that Project Management, Design, Testing and everything else won’t be impacted. The trouble is that Agile is all too often discussed, described, evaluated and generally understood as it applies to development only, leaving other aspects of the project lifecycle out in the cold.

The Methodology Myth

I have been in startup development environments for my entire career. And if there is one concrete, immutable fact I have learned it is that no startup environment is mature or stable enough to completely adopt and implement any pure methodology within any discipline — not requirements, not development, not project management, not testing. It simply does not happen — nor should it. While most development environments will dabble with some aspects of Agile, the fact is that — like all process — it is typically really a hybrid between a couple of different approaches, in combination with some home grown goodies, that is all tossed together to come up with something that fits the organization. Any other approach is folly.

You Say Potato, I Say Potaaaaaaaaaaaaato

One of the problems that has evolved over the years when it comes to Agile is at the heart of it’s value. As a methodology, Agile is specifically about results more than form or procedure. As an execution-oriented person in startup environments, I praise the focus on results. However, as a project manager, I also have to say that I have seen far, far too many developers use the methodology as an excuse for being lazy and sloppy about writing documentation. I used to debate with one of the Development Managers/Architects at JetBlue all the time: he was a huge advocate of adopting Agile methodologies, and I would always tell him that he needed to be careful of the language he used, unless he wanted to see a backlash from project and functional managers who’d been burned by this in the past.

He Said, She Said

Another problem with the language we use to describe Agile (in combination with the myth that it is or should be a dev-only consideration) is that, grammatically speaking, the word agile and the name Agile are often used interchangeably, even though they are not identical. This is particularly problematic when it comes to non-tech executives who hear “agile development” and think that means they are just going to get their project executed more quickly. All too often, I’ve seen Agile evangelists “sell” leadership teams on the idea that Agile is the way to go, without ever really explaining (in business-speak) what that means, what that will take and why it is of value. Even worse, most of the time, those evangelists actually think they really did explain it well.

Pragmatic Agnosticism

In the end, however, my biggest reason for not including the word “Agile” in my presentation is because, when it comes specifically to the core project management disciplines of communication, documentation, change management and entry/exit criteria, methodology agnosticism is key. This is never more true than in a startup where things are guaranteed to change before you have your Gantt Charts unpacked. Some of the tactical details may be different — whether it’s roles and responsibilities, sequence of events, etc. — the the underlying tenets are the same. And any project manager who says that communication, documentation and change management are fundamentally different in an Agile environment vs. a Waterfall environment are blowing smoke.

In the end, project management is a disciplined centered around the concept of integration. And integration is about effectively combining the efforts and products of multiple different disciplines into a final product of value. That can’t happen without communication, which includes at least some degree of written artifact (often around entry/exit criteria), and managing the inevitabilities of change. So, in a 45-minute presentation, it made more sense to me to skip over the great and eternal methodology debate, and move straight on to the basics that universally apply, regardless of what approach a team is taking to getting the work done.

I’m not entirely sure that the person I was speaking with agreed with my approach. And, in hindsight, I should have taken a moment at the beginning to state that I was going to be speaking from a methodology neutral standpoint. Definitely my over-sight there. I’ll be more conscientious of that in the future.

But people who want to get religious about a methodology can espouse whatever they like, but in the end, you have to be pragmatic in order to deliver a project (much less a recurring series of projects). And zealotry is never pragmatic.