Skip to content

What I thought Agile was About

Lately I’ve been wondering if I fully understand the agile methodologies movement. There are some things I like, such as iterative development, quick response to changing requirements, and daily (or better) builds. There are also some things I’m not so sure about, such as daily meetings, 100% pair programming and bullpen type work environments. Those are the specific techniques agile people are pushing, but it is the way they push agile that is bothering me. More and more I’ve been reading articles and forums as well as attending a few talks that lead me to believe we are going down a similar road with agile methods that we did with the old style methodologies. The attitude I’m starting to get from agile pushers is “do these X things, your problems will be solved and if they aren’t solved then you aren’t doing the X things correctly” or “You don’t do agile methodology X…tsk, and you call yourself software developers”. Sound familiar?

I’m not saying that agile methods never work. I’m saying that they don’t always work. I know they don’t always work (without having done any sort of scientific study or research) because I know that, like Fred Brookes said (and he said it a REALLY long time ago) there is no silver bullet. What I thought agile was about was being _agile_ in changing quickly what is not working. That is, software developers (both management and code monkeys) can’t be afraid of changing and changing quickly if a technique or process is clearly busted. This is what I thought agile development was about and I’m hoping this turns out to be true. There is nothing that will fix everything in one fell swoop, so I’m still confused why we are even still trying to find the silver bullet.

We need to do stuff that works and change stuff that doesn’t. Simple right? Agility necessitates change.