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.
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009