By Billy Lee Heywood

Every once in a long while, we all rise to a level of consciousness far above our peers, for just a moment, where we have great clarity and understanding. It is this enlightened perch from which I write.

For those who haven’t heard, the tech world has gone “Agile”. But what does this really mean? Is it a severe paradigm shift? Like when linear programming took a back seat to event-driven programming? Or is it yet another here-today-gone-tomorrow fad with a catchy name?

Let’s assume it’s here for the long term. Because it is. Deal with it. So, what are we going to do about it? Are we seasoned, complacent warriors going to fight it? It’s tempting, right? So much shit comes our way, every minute of every day. Some from industry giants and respected trend-setters, others from some asexual dork locked in a closet in Topeka, Kansas with five infrared laptops, a blue tooth in his ear, a Geeks-R-Us t-shirt, and a box of ring dings. We resist, rightly so, the widget that attaches to the thingy that attaches to the other widget, because, although it may be cool to 1% of the people 1% of the time, it has the exact characteristics of “stupid” in every other way.

But this new project strategy, called Agile, in its current form, is going to affect most of us. And, if you could keep a secret … the term has been around at least five years, and flavors of it have existed much longer. When they started throwing around the word “Agile,” my initial reaction was to resist and fight. It’s who I am. It’s what I do. Until I found out that it’s actually pretty cool, and lots of it I am proud to say I’ve already been doing for a long time, way before they gave it a name. No, really, I’m not saying that makes me a genius or anything, but, hey, go ahead and draw your own conclusions. Because you figured out that the mouse thing makes the arrow on the screen move, you’ve earned the right to judge me.

I’m guessing that if you consciously clicked on this blog, you probably know what Agile is. But, because my over-achieving entrepreneurial college roommate asked me, I need to write about it. I’ll start with the good news. In the Agile Manifesto, they do insist on a 40-hour work week, and nothing more. Nice. Agile development is when we chop up a big project into insanely short deliverables, throw out the demand for fluffy documentation that is outdated by the time the ink dries, force the team to talk every day for a predictably short amount of time, and challenge ourselves to get the work done. Sounds a little Wild West, but at the end of one of these cycles, or sprints, or whatever the book you’re reading tells you to call them, we’ll have something to show for our efforts. And then we all stare at it, make decisions, and start another cycle. Lather, rinse, repeat. Until we have a product that satisfies the main stakeholder.

So, where’s the rub? (And what does “rub” mean?) What’s the downside? Where do we need to beware? Well, while we’re all real proud and bumping chests and slapping butts and cutting through project after project like OJ cuts through ex-wives, what happens in six months? A small change; an enhancement; a bug. Who goes back to fix it? How? Who the hell remembers the cyclone of activity that led to the final product, many months and projects ago? Certainly not I. I can’t remember what I had for breakfast this morning.

To make the process work over the long haul, there needs to be some attention to discipline. As we all hold hands and jump from the Agile cliff, let’s be sure to remember that someday, someone else will need to pick up where we left off. The more we can document our adventure, the better off we’ll all be. The more formal and predictable the process, no matter how renegade it may have been, the better it will serve the next poor slob chartered with maintaining/enhancing the project. Other than strong commenting in the code, and some high-level system diagrams, I can’t make a suggestion of how this process should look. That would be very non-Agile of me. So it’s up to the people on each team. Just be sure to make it a priority throughout each cycle, and not an afterthought. Otherwise the time you saved tearing through project after project is sure to be lost many times over in the maintenance / enhancement phase. Other than that, Agile will get you where you want to go. I promise.

I know, I know. I had you at “40-hour work week”.