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

Comments

  1. I completely agree with you. In our current project the BAs are extremely valuable. They know the business, collect information of all possible stakeholders and have a good technical understanding. Probably depends on people and not on job titles or roles!

    ReplyDelete
  2. Awesome! There's some relationship between people, job titles, skills, and roles, but it's really hard to wrap your head around it algorithmically from a staffing perspective!

    ReplyDelete
  3. here here.
    I've ended up as a PM and I can tell you that not only do I not enjoy it, but it requires a very different skill set from what I've developed as a dev... oh and did I mention that I've also ended up as the BA and I quite enjoy that but it requires a very different skill set from... well you know the rest.

    I find it really hard, for example, to write stories without the implementation implied by my wording. I find it really hard to not throw in a dozen 'technical' stories with no business benefit. I know BAs who are much better at ascertaining the real business need, rather than the one the business is telling me.

    I can do all these, but I am slow and clumsy and don't feel 'natural' doing them. Please give me a great BA (and PM) so I can turn great stories into fantastic software, rather than mediocre stories into mediocre software.

    And remember Cockburn also said 'People [are] first-order determinants' in project success. People are great at different things, and some people are great at things that the role BA gets attached to and some are great at things the role QA gets attached to etc etc

    ReplyDelete
  4. Hi Elena:
    thanks.

    seems that having oxymoron in the title for this topic is popular -- I've had presentations i've delivered for spin and iiba chapters over the past several years entitled, "Agile Requirements: Not an Oxymoron" OR "Agile Business Analysis: Not an Oxymoron".

    my blog post with the former title from June last year provides my take, please see:
    http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/

    analysis is a shared responsibility, whether the role exists formally or not on agile teams.

    indeed, analysis and planning are synergistic (look for article in next issue of Better Software on this); and qa/analysis are also synergistic (i'm co-delivering a workshop at Agile 2011 with Janet Gregory, coauthor of agile testing, on this important topic).

    thanks for your post!
    ~ ellen
    www.consulting.com

    ReplyDelete
  5. Hi Ellen,

    I apologize for not checking to see whether the oxymoron title was already taken! I feel consoled to be accidentally standing in such big shoes, though--I really love your work.

    I look forward to reading your further discussions on this topic. Cheers!

    Elena

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica