Ok, I just got back from vacationing in the Gulf of Mexico and I feel reenergized...so reenergized I feel like writing a bit!
It seems that all I hear about is Agile development methodology anymore. User groups and Special Interest Groups (SIGs) have even changed their names to reflect some connection to Agile's methodology, but still I can't help but wonder what the whole Agile movement stems from. If I think back to what I learned in college, my thoughts are drenched from listening over and over about the Waterfall methodology. This was what colleges were training young graduates to use once we hit our first job, but 10+ years ago technology was much different.
Let's talk a little about the Waterfall Methodology. The Systems Development Lifecycle (SDLC) was a little bit different then. Development started with Planning and once development of the gathered requirements was finished and the solution was deployed, the lifecycle ended with Maintenance. If changes were needed, well then the lifecycle started over again. Well back then technology was different or should I say harder to develop. There really was not the level of Rapid Application Development (RAD) like there is today. Other than Joint Application Development (JAD) sessions, clients were not as involved with the overall development lifecycle. Business/System analysts were just then making their ways to the front lines because developers were still somewhat tucked in the dark depths of basements, looking for their staplers. Most importantly, we did not have .Net!
Development as a whole has shifted its paradigm beyond just code and flow charts. Developers really benefit from learning the business and what better way to learn the business then to focus on customer needs. More importantly, how do we effectively communicate with customers and clients to show that we understand their needs? Looking at Agile development, you will see that clients are involved from day one till the end. Understanding this concept, developers must anticipate flexibility when architecting solutions. Working close with anyone, you can see how different approaches would be considered. So what does technology today offer to support these agile changes during development? First, consider some of the frameworks used to assist us with development. My favorite is Object Relational Mapping (ORM). This type of framework allows the flexibility to handle ever changing requirements, which are made on a dime. Consider LINQ for data and the Model View Control (MVC) Framework for ASP.Net, and more importantly Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF). I cannot tell you the number of changes I have had to make for clients in which WF has been my best friend by consistently supporting how new changes were implemented, and communication, where different protocol handlers would have to be hand crafted.
What does this all mean? Probably that changes clients make are inevitable, and technology has painted a better road map by allowing choices of how to tackle changes quickly and effectively. This does not mean that Agile should be used for all solutions. Agile will probably not work when you are dealing with rather large development teams or with clients in which you have limited communication, visibility, or when clients need a figure based on requirements up front, so they can see how much a solution will affect their budget.