Agile Alone?

Is it possible to work alone and produce Agile-quality code at the same time? Here at Atomic Object we try to practice pair programming whenever we can, but there are times when it doesn’t work out that way for a project. As fate would have it, I have just come off three consecutive assignments covering a period of over a year that involved working alone for a great majority of the time. I’ve been an agile development proponent for more than five years now and I do actually try to practice what I preach, but my experiences over the last year have tested the bounds of what I would consider “Good Agile Practices.” In this post I’d like to share some of these experiences and describe some of the steps I took to try to stay on the Path.

One of the greatest challenges I found in working alone is getting past technical and conceptual hurdles when they came up. Being stuck with just my brain and all of its prejudices and limitations sometimes made it difficult to come up with alternate strategies when things weren’t working very well. One example of this occurred when I was tasked with increasing the performance of a tool used to generate reports using data read out of a proprietary database. After trying several things that should have made a difference but didn’t, I realized my mistake while frustratingly showing a coworker (who was working on a totally different project) some code that just wasn’t doing what it was supposed to do when he pointed at a different method and said “What is that doing there?”

This is my first suggestion for working on your own: Don’t work on your own. Whenever you can, solicit someone else’s opinion. Get another pair of eyes on your problem. Try trading code reviews with someone else that is stuck working alone. Even if they have no idea what you are working on, just the exercise of explaining it out loud will often help you see things you didn’t see before. This is especially true if you find yourself getting stuck on an issue. Talk it up with others. Also, (as with all things) Google is your friend. Maybe you can’t work with a partner, but odds are someone else has run into your exact issue before and has written about it on a blog or a forum. Recently, I’ve been finding great hits to my technical questions on Stack Overflow.

Another issue I ran into occasionally was one of focus. It didn’t fully occur to me until after I had been without a development partner for a while, but working as a pair is a terrific tool for keeping both people focused on the task at hand for longer periods of time. When working alone it is much easier to get distracted by an incoming email or IM, or to get off track by following an interesting, but unproductive tangent to the task at hand. About the only suggestion I have for countering this obstacle is discipline. If you want to stay focused on a task, close your browser. If a tempting side idea pops up, write it down on an index card and return to it later. Try finding a quiet place in the office (or out of it if that option is available to you) to get away from phone calls or walk-ups.

One last technique I’d like to share is putting extra effort into the good programming practices that you can do. Even if you aren’t pairing, there are many agile development methods you can employ to keep your production quality and quantity up. Not having that extra voice to help head off mistakes, I tried to use other techniques to limit errors. Unit, integration and other tests, for example, become even more important when you alone are responsible for the quality of the code.

I believe it is possible to work alone and be agile, but it can definitely be a challenge. I recommend working as a pair. For those times when you cannot, remember these tips and increase your project’s prospects for success.