For the past year or so, I've been reading up on Agile Development and how it could be used in my work. I mainly focused on Extreme Programming (a.k.a. XP), but was just mainly interested in the culture change and what the key elements were in making Agile Development successful.

Agile Development methodologies like XP aren't really too hard to understand. XP specifically has a set of guidelines and practices that you apply to implement Agile Development. In my opinion, the practices are effective enough that it would be almost impossible to not see a benefit if they were applied honestly.

Even though methodologies like XP are easy to understand, they can't always easily be applied. At my last job, my development team looked into XP and general Agile principles. We never went through with it though, and I believe it was because of two main reasons: 1) lack of customer involvement in projects and 2) not enough buy-in of Agile Development from team members.

In short, at my last job our (internal) customers were spread across the entire United States and were not willing to spend time on the phone on a frequent basis to be involved with their projects. Our team was often looked to as experts that could solve our customer's problems with minimal participation by the customers themselves. I believe that the one lynchpin of Agile Development is communication. Without it, Agile Development will fail.

Some technical staff did not completely buy in to the Agile ideas. The most common remark was "how can we build good software without knowing all of the requirements up front? It would be foolish to have to refactor software later when you could gather all of the information up front".

Agile Development does not ask technical staff to be ignorant about forseeable problems or to design software such that it is difficult to maintain. Refactoring is one of the key components of XP and it is done continuously. Change is welcomed by XP because it is designed to deal with changes in an effective way that improves the overall design of the software. Unfortunately, even after going into specific details and examples about XP to address change, the technical staff still didn't buy it.

I left that job wondering if I'd ever get to experience Agile Development in my career, and then walked into a new job finding that I'd be experiencing it right away. At my new job, Agile Development is an initiative that is gathering a lot of speed among the staff, and some projects are already practicing it (including mine).

I'm both excited and suprised at this new horizon. I'm excited because I really believe that Agile Development works given what I've reasearched. I'm excited to be a part of an organization that shares my belief and that is equally excited about practicing Agile methodologies. Why am I suprised? I'm suprised that Agile Development hasn't caught on more quickly in organizations. After finally being able to work on a project while practicing Agile Development, it feels so natural. It will be difficult to go back to the old Waterfall approach. My current project is moving quickly and my team has confidence that we will be delivering a high-quality product that meets the customer's expectations.

I'm eager to see where this road goes.