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
3 comments:
Have you finished that whitepaper, by any chance? I'd be very interested in reading it. Because anything I read about Agile so far sounded more like religious pitches with no substance.
The white paper turned into a book project. A fair amount of the book content either originated on this blog or has been posted as blog entries. The problem with a blog of course is that the material isn't as well organized as a white paper or book. But it has been a great way to learn and to get feedback and fine-tune my thinking about Agile.
I've also produced a 1 hour PowerPoint presentation which is currently my best material for making the case for Agile in a very nuts and bolts way. I've been toying with breaking that up into short youtube clips, but haven't done it yet.
However, I did write an article a while back which I think is pretty good on the substance side and hopefully devoid of religious pitches. That's Breaking the Major Release Habit .
I look forward to continuing the discussion!
Nice Article Damon!! I think Agile development models addressed the shortcomings associated with traditional project management models in meeting the ever-growing environmental demands and expectations that organizations were facing.For more details, please follow: https://www.scrumstudy.com
Post a Comment