Being Agile is Hard

Scott Bellware is having some “fun” over on his blog trying to explain why he is a fan of, and practices, Agile development. He’s frustrated because, in his experience, many people have misconceptions about what TDD, XP, Scrum, etc actually are, and then go on to attack these processes based on these same misconceptions.

Keeping to that theme, I’ll present a few of my observations. First, some background about me.

I started my life as a developer very recently… I graduated with a Computer Technology diploma in late 2002. One of my instructors happened to be Grigori Melnik, a Russian robot without an “off” switch. He had us pair-programming on assignments, and writing simple tests before we wrote our implementation. He also spoke a lot about XP practices, so you could say that I was indoctrinated right from the beginning.

So you’d expect that when I entered the “real world” of development, I’d dive right in to using these same Agile processes, right? Well, no. I can honestly say that I was mostly convinced of all the benefits, but actually practicing them was hard for the following reasons:

  • Tool support sucked. Unit testing wasn’t integrated into Visual Studio, and there was no refactoring support at all.
  • I had difficulty working with others in a pair. Communicating is hard, and takes practice, especially when you’re in a new field.
  • Writing tests from scratch is very hard, unless you’ve got some mentoring.
  • Coding by yourself can be almost therapeutic. Pop in some headphones, crank up the Styx, and get in the groove, baby.

For these reasons, I never really rocked out to the Agile beat. I knew about it, I had been around it my entire programming life, but it never really took hold. This is where we come back to the part where I get on topic. In Scott’s post I referenced above, he states how he’s basically come to the conclusion that Agile cannot be taught or evangelized through the written word. So he started teaching courses and speaking at user groups. Walking people through it. Letting them try stuff out under an experienced watchful eye.

I think this is the only way someone can really get what an Agile practitioner is talking about. If someone like me, who came into the development world after XP and Scrum had been developed, who had instructors teaching me this stuff from the get-go can’t latch onto the concepts without help, then what are the chances experienced developers are going to latch on? They’ve been pumping out code for years, probably doing quite well for themselves, so why change? How many other “red pills” have come along in their time, only to be shat out the other end without the promised effect?

All I can say to Scott is to keep doing what he’s doing. It probably does make a difference to many people, and may even help them code better. But even with all the benefits, there will be those who just will not be Agile. We’ve offered at least a few people jobs on my current project, only to have them take one look at “The Pit” and say “This just isn’t for me, sorry.” I remember showing our workspace to some former co-workers. They stared around at our expansive setup for a while, until one of them said, “I have way more space in my cubicle.” Whoa. Touche.