I'm interested in hearing people's first and/or current impressions of Agile development. Here's mine.
My first real encounter with Agile development was at the Software Development Best Practices conference in September of 2005. Up until then I had managed to be all but ignorant of it. I was at the speaker’s reception, and unbeknownst to me I had been dropped into a den of Agilistas. They all looked like perfectly normal people to me. Conversely, they all seemed to assume that I was “one of them.” But then they started talking to me about 3x5 cards, pair programming, collocation and the like.
I wondered why these crazy people thought it would be a good idea to send poorly tested software to customers on a weekly basis. And what were they thinking doing their planning by shuffling around 3x5 cards with notes scratched on them? These folks were talking about writing software while sweating hip to hip with a fellow programmer all day as part of a two-person programming team in a small cramped space in close proximity with lots of other sweaty two person teams. And when I objected I was treated as a heretic that “just doesn’t get it.” To top it all off, this stuff is all written up in a Manifesto!!
I wanted to run as far as I could as fast as I could. In talking to other people about their first contact with Agile, I have found that this initial negative reaction is quite common. My reaction was so strong I decided to put together a whitepaper pointing out all of the problems with Agile and introducing an alternative to Agile which could be loosely described as “process and tools done right.” I felt that Agile, and especially Extreme Programming, was an overreaction to unwieldy project management, process, and tools. The more research I did for the paper, the more I found to dislike.
Along the way, I finally realized why Agile is a good thing. But, it took me close to six months of active research motivated by my dislike of Agile to see the light.
There really is something significantly new, different, and worthwhile lurking in there and it doesn't require small teams, pair programming, working in an open area, 3x5 cards, or fanaticism. This blog is an attempt to examine the benefits and inner workings of Agile from a technical perspective. That is, what exactly are the benefits, how exactly are they achieved, and why is it different than traditional development.
Describing Agile is a bit difficult, let's take a look at it at a high level to start with.
Next: Agile in a Nutshell