Agile Business Analyst Is Not An Oxymoron

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.

Tom Smykowski, Office Space BA

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.

1. Even On Agile Teams, someone still needs to facilitate discussion, record consensus once reached, and analyze the business/technical flow of data.  The best business analysts were never the people who doggedly filled out every template to completion--BAs at their best have always facilitated discussions, promoted development ideas to "the business," and urged people to talk directly to each other.  Blaming BAs for "Big Upfront Design" is no more appropriate or helpful than deriding developers as pocket-protector wearing individuals with thick glasses who only communicate in binary.
2. Time Has Told.  Although the Manifesto and Agile Founding Fathers originally thought of all agile team members as developer generalists (or--dare I say it--old fashioned "programmer/analysts"?), time and experience have dis-proven the hypothesis that BAs aren't needed for agile.  Modern Analyst quotes Alistair Cockburn in 2009 saying:  “the early attempts at Agile development tried to do away with the Business Analyst” because of the potential distortion of communication with a go-between. However, given the complexity of organizations, the disparate business languages that various units may use and the time constraints of subject matter experts, "more recent variations are finding good use for someone with deep business knowledge, who has time to spend talking with the programmers.” 
3. Corollary:  Time Is At A Premium.  As Cockburn says, some agile teams may gain benefits from a division of labor whereby business analysts stalk, cage, and interview disparate organizational stakeholders, always time consuming practices, in order to present a coherent set of stories to developers, who can then focus on the actual development.  This is not because the developers are not capable of understanding the stakeholders, but because facilitating consensus is a different activity than writing actual code. 
4. People Have Preferences.  As actual agile teams have been born and gone out into the world, it turned out that everyone didn't want to be a developer.  Speaking generally, some people wanted to work with people, some people wanted to write algorithms, and some people wanted to develop psychotically completest edge cases to guarantee quality.  So although agile teams have often offered everyone the opportunity to do a little bit of everything, gradually the roles of BA, Dev, and QA have emerged as personal expressions of interest by team members.  One could argue that things have now gone too far, and people have hardened into their job titles, but so long as teams (or companies) offer people the chance to continue to learn and grow, it isn't necessary to jump to the conclusion that the presence of BAs or QAs on an agile team is caused by HR departments blindly filling out a template somewhere.

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."