Skip to main content

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

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …