I am not sure why so many people seem heated with the mention of agile development. Most of the concepts of agile development are not new. Anyone who has worked on any Rapid Development (RAD) projects in the past 10-plus years has followed many of the agile principles. The RAD process is considered the forerunner of agile methods (such as XP and Scrum). In those old days many of us followed the advice of Steve McConnell (Rapid Development: Taming Wild Software Schedules. Redmond, WA.: Microsoft Press, 1996) and we found that when project innovation was needed, we had great people both from the business and IT side who were co-located. We had access to good case tools, and we followed a strict time-boxed project plan for delivery, and the process actually worked great and produced some darn, good software.
Now it seems that many Business Analysts worry that agile means no process, no documentation, and no Business Analysts will be needed to participate. I disagree. What I see as one major difference between agile development and traditional waterfall development is one of documentation; how much is needed, why is it being done, and when it is done.
Traditional development processes such as waterfall are very prescriptive and have a set of required document deliverables. This type of development process has been working great for years on many large, complex projects. It still works, but it is not my favorite approach. Agile development stresses full involvement by the business, early prototyping, purposeful documentation and continuous evolution and delivery of prioritized working features on a software product.
Great Business Analysts are still in demand on agile projects. Seasoned Business Analysts don’t need a prescriptive process to figure out what to do. In an agile environment, what will be needed is an experienced Business Analyst who understands different techniques and how they can be used to take advantage of an opportunity or to help solve a problem in the most efficient way. It is hard to argue with any of the fundamental principles of the Agile Manifesto. Waterfall or agile: Either can be effective in certain situations and each process is only as good as the person applying it.