I was a beautifully warm night in late December down in Jervis Bay. My friends and I had rented a holiday house for the New Years weekend and we had spent most of the day drinking and soaking in the sun, our professional lives a million miles away. We had been enjoying all manner of activities from annoying our significant others with 4 hour bouts of Magic: The Gathering to spending hours talking on whatever subject crossed our minds. Late into the evening, in a booze fueled conversation (only on my end, mind you), we got onto the subject of Agile development methodologies and almost instantly I jumped on the negative bandwagon, something that drew the ire of one my good mates.

You see I’m a fan of more traditional development methodologies, or at least what I thought were traditional ideas. You see I began my software development career back in 2004, 3 years after the Agile Manifesto was brought into existence. Many of the programming methodologies I was taught back then centered around iterative and incremental methods and using them in our projects seemed to fit the bill quite well. There was some talk of the newer agile methods but most of it was written off as being experimentation and my professional experience as a software developer mirrored this.

My viewpoint in that boozy conversation was that Agile methodologies were a house of cards, beautiful and seemingly robust if there’s no external factors on them. This hinged heavily on the idea that some of the core Agile ideals (scrum, pair programming and it’s inherit inability to document well) are detrimental in an environment with skilled programmers. The research done seems to support this however it also shows that there are significant benefits for average programmers, which you are more likely to encounter. I do consider myself to be a decently skilled programmer (how anyone can be called a programmer and still fail FizzBuzz is beyond me) which is probably why I saw Agile as being more of a detriment to my ability to write good code.

After taking a step back however, I realised I was more agile than I previously thought.

There are two methodologies I use when programming that are included in the Agile manifesto. The first of these is Extreme Programming which underpins the idea of “release early release often”, something I consider to be necessary to produce good working code. Even though I don’t announce it on this blog every time I get a new feature working I push it straight into product to see how it fairs in the real world. I also carry with me a copy of the latest iPhone client for testing in the wild to make sure the program will function as expected once its deployed. Whilst I don’t yet have any customers other than myself to get feedback from it still keeps me in the mindset of making sure whatever I produce is workable and viable.

The second is Feature Driven Development, a methodology I believe that goes hand in hand with Extreme Programming. I usually have a notepad filled with feature ideas sitting in front of me and when I get time to code I’ll pick one of them and set about getting it implemented. This helps in keeping me from being distracted from pursuing too many goals at once, making sure that they can all be completed within a certain time frame. Since I’m often coding on the weekends I’ll usually aim to get at least one feature implemented per weekend, accelerating towards multiple features per weekend as the project approaches maturity.

Whilst I haven’t yet formally conceded to my friend that Agile has its merits (you can take this post as such, Eamon ;)) after doing my research into what actually constitutes an Agile methodology I was surprised to find how much in common I shared with them. Since I’m only programming on my own at the moment many of the methods don’t apply but I can’t honestly say now that when I go about forming a team that I won’t consider using all of the Agile Manifesto to start off with. I still have my reservations about it for large scale solutions, but for startups and small teams I’m beginning to think it could be quite valuable. Heck it might even be the only viable solution for small scale enterprises.

Man I hate being wrong sometimes.

About the Author

David Klemke

David is an avid gamer and technology enthusiast in Australia. He got his first taste for both of those passions when his father, a radio engineer from the University of Melbourne, gave him an old DOS box to play games on.

View All Articles