I just read a very angry blog entitled: Business Analysts And The Million Dollar Question - What Would You Say You Do Here? The author quotes Scott Ambler's famous line, "Remember, 'BA' is also the abbreviation for band-aid" and he goes on to say that if you hire a typical BA, chances are high that "you're not just wasting your money; you are, as a matter of fact, risking your project by introducing an additional monkey that'll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work." Okay, then.
The Agile Manifesto itself seems to be taking a direct swipe at Business Analysts when it talks about valuing "working software over comprehensive documentation"and "customer collaboration over contract negotiation." Somehow, Business Analysts have ended up as a proxy for everything bad about the "Waterfall" development method: Big Upfront Design, Big Documentation, Bad Communication, Silos, Cholera, Blunder-headed Filling Out of Templates, the works. Oh, wait, not cholera. But you can see how it would accidentally get into the list--that's what happens when you start to write things down unnecessarily. Next thing you know, you're gold plating.
But let's take another look at this. When we're pragmatic, rather than dogmatic, we tend to find that business analysts are proving to be as vital for agile project teams as they were for the first struggling dev-only teams in the dark days before they invented "waterfall." Let's break this down a little bit.
There has been a flood of conversation among my peers recently about the "role of the user experience designer" versus the "role of the BA," and it is beginning to degenerate in a manner very reminiscent of this Dev versus BA conversation. One colleague posited that the BA position should be eliminated in favor of a combined BA/UX position on each project. Why must this always be so zero sum? Some people have excellent design ability, some people have excellent skills for breaking down functionality into easily digested pieces. Not everyone has both of these skills, and even if they do, not everyone enjoys doing both types of work equally. So far as I know, the last human who ever knew "all there is to know" was Goethe, and that was a long time ago. There's a lot more to know these days, a lot more mistakes to be made, and a lot more experience to be hard won.
So to me, the bottom line in all of this discussion is that the fundamental unit of agile production is the team. The team should combine a number of diverse skills, analytical, communicative, creative, quality-minded, dev/ops, and good-design-informed. As you put together your team, you should make sure that you have all of the skills needed, from some combination of interests, experience, and skills of the team members. People will have a combination of generalist and specialist capabilities, and people should hopefully be emotionally as well as analytically intelligent. But you know what? It's absolutely fine to start by setting up a ratio of one BA, one QA, and two pairs of Devs, and then correct for missing skills.
It is certainly better to do so than to start tinkering with theories like "<my job title here> can be trained to do it all, and the rest of you are monkeys."