28 November 2007

Do we need Agile Business Analysts?

Don’t be fooled. Agile projects threaten the role of business analysts on IT projects.

An important thing to consider for Agile projects is that users need to be senior enough to be able to look beyond local agendas at broader business benefit.

Furthermore, the BA can be the one to add that broad view, but can't replace the senior user, as unless they have worked in the role they can't really know it. Additionally the business unit hasn't ‘bought in’ to the new system if done by proxy through a BA. The business definitely needs to send in their user/s.

We had a short discussion about this topic at Better Projects a while back and the consensus was that a BA can't replace the business representative on an Agile project – mainly for the above reasons.

In fact, on Agile projects the developers are expected to do the analysis in an agile project. That’s why they require A-grade team members and work best in less complex business environments.

Potentially a Business Analyst can participate in the team to add depth and skill to the analysis. Certainly they could be working on the next (or future) iterations while the development team are busy building this round.

Another alternative is that the skills of the business analyst are adopted by Agile developers. Teaching Agile development teams the disciplines of business analysis will help them accommodate more complex business environments and deliver more consistent results and in the end better projects.


  1. Two and a half years back when I joined ThoughtWorks I was roughly of the same opinion. Today I strongly disagree with the view that Business Analysts can be done away with on Agile projects.

    Here's why.

  2. As I posted at Akshay Dhavle´s, I still have hope.


    I agree about the developer´s point of view.

    We are implementing a new process involving BAs and system analysts. BAs work on the BRD (mostly use cases and static models), and they get from there.

    This week a developer came to talk to me about their documentation, what they should use, what they should consider and he was concerned about requirements tracking, and I said that it has no use for us because we describe our functional requirements on use cases.

    I don´t want to discuss the approach, the interesting part is what he asked and it was "what if the client asks to change something in the middle of the project, how do I track it back?"

    I said, "dude, they won´t, we fight till death to guarantee stable requirements before you do your analysis, that won´t happen".

    Well, the look is his eyes betrayed the feeling of taking a hundred tons from his back, now he could focus.

    Ok, it´s a big promise, but we are handling it well since we showed the client that a good business analysis is the basis of a good project managing that´s the basis of something they love: to be sure of something.

    Another interesting stare I received came from the UI designers when they heard they would get well described and again, stable functional requirements from us.

    I believe we have a big gap to fill and someone should treat the other parts of the process as clients. We do it.

  3. Thanks for the feedback guys.

    In a way it was a provocatie post aimed to generate discussion, but from a certain point of view I think my post holds true.

    Agile is about doing things faster with less bureacracy. Business analysts are a part of the bureacracy and they slow things down.

    BA's are about creating a definitive standard for requirements, about thinking deeply about the problem space and making sure you are putting together the right solution.

    Of couse we are talking about a binary world where projects are one type or another. This is done to illustrate the point.

    In reality projects draw on a number of tools and processes from a variety of place - and they are never cleanly configured for one particular model.

    Akshay - that would be where your scenario of a BA adding value kicks in.

    And Kerber's example is another common one - where the BA adds discipline to the business by getting them to understand what their requirements really are so they can stabilise before development begins. (Although stable requirements are an indication an Agile approach is not really required.)

    And thanks again Ashkay for another post. I've been waiting for a while :)

  4. Craig, sorry I have to ignore your closing note for a while and keep going at this discussion because I am upset about what Kerber posted.

    If I have understood Kerber's comment correctly, the gist goes like this.

    "We are almost there and if just try a little harder, we can make these requirements watertight enough. The team will be happy then"

    I am upset because once again I see that people have lost sight of the actual objective of writing software.

    Software is NOT created so that we can show how requirements can be watertight.

    It is NOT created to make the developers/UI designers happy.

    It is not created as a demonstration of how you can stick to a timeline and a budget.

    Software is created to make someone's life easier by adding value to an existing business idea OR by creating a totally different business idea with the help of technology.

    The someone that you're trying to make happy, is the "end-user" of the system. Everything else, is only a by-product.

    Software is for users

  5. Akshay, making software to make the life of the end user better is so basic that I did not think I had to say it in my comment.

    We are very into it, but we realized that you can make the user happy and also make the developers and designers happy, one thing does not excludes the other.

    Just a reminder, beaurocracy is not bad, we need it, the problem comes with "beauropathy".

    It´s great to discuss this subject with you guys. Don´t bother if I vanish for a while, got two weeks to go to the beach (it´s summer here).

  6. Anonymous3:44 am

    Maybe this is a case for having a business analyst as a member of an agile dev team. That way, not every developer has to try to think like a BA (which she probably wouldn't enjoy much anyway), and the BA can help the team move effectively forward.

  7. Kerber, you are totally right, but you missed my point entirely.

    Making users happy and making devs/designers happy are not mutually exclusive things.

    Having rigid requirements and making users happy ARE mutually exclusive things.

    But I think I'll leave it at that coz we are getting into agile V/s non-agile again :p

  8. Carl, what do you mean by "having the business analyst as a part of the agile dev team"?

    Agile teams always consist of Devs, BAs & QAs. At least from what I have seen.

  9. Anonymous11:38 am

    In my world we build software that is fit business purpose. Software is build to make money for someone. Making users happy is only a priority if that is part of a business strategy. This whole debate demonstrates why BAs (and well managed requirements) will always be essential in a business environment – to ensure business requirements are balanced against developers’ need to build cool stuff.

  10. Having just emerged from a project with an agile methodology I also have to disagree with your warning about doing away with BAs.

    Our conceptual design phase elicited requirements led by an Information Architect, and collected, analysed and documented by our BAs, who then fed them to the developers.

    Fortunately, the developers were no where in sight -- they had big problems with our iterative processes, and couldn't keep up with us as we peeled each layer of the onion.

    Ultimately, more BAs need to know how to do prototyping and storyboarding -- the tools of the agile environment.