Cultural Barrier Between Agile and Traditional Business Analysis
You may have already encountered considerable cultural barriers in the practice of business analysis. It has changed as traditional software development environments are giving way to agile software development environments. These changes have a profound impact on the way you or a team member might need to adapt to new, more agile ways of doing business.
The issue is that traditional business analysis is "heavy" - that is, it is characterized by over modeling and overly detailed specifications. On larger, longer term projects, this has been the way, and perhaps it is appropriate. However, agile approaches demand a different approach to business analysis.
Agility implies flexibility, dexterity, alertness, adaptability. It implies the ability to think more on your feet, and less by yourself at your desk! And it implies an ability to become more embedded, on a day to day basis, on project teams throughout the entire cycle of a deliverable. And, finally, it implies speedy - albeit not hasty - identification of issues, development of requirements, and validation of deliverables.
The function of business analysts is just as necessary and important on agile projects. That has not gone away, and is as vital as ever! It is just done differently. As project life cycles are drastically reduced, constraining the scope and timeframe for a set of requirements, the way business analysis needs to be done also changes. This change, I think, is actually an opportunity, and an improvement. The premise is that agile has evolved because the old way was too stodgy, unreliable, and problematic. It sounds logical to think everything through up front. However, the further you extend the time horizon, the hazier it gets, and the more complex the downstream tasks become. The idea of agile is to keep things within that short timeframe where the analysis that is done is highly accurate, well understood across stakeholders, and actionable for quick delivery.
Habits are hard to break, and training and work practices become ingrained over time. If you are a business analyst who has focused on BA for some time, you may have some ingrained ways of doing things, and they may have served you well. However, at some point, if you have not already, you will need to fit into an agile team of some sort. And you may have to struggle a bit to adapt to a different way of doing business analysis.
Again, the function of business analysis is no less important on agile projects than traditional waterfall projects. But it is less of a "specialty". The difference is analogous to comparing a position in a large organization versus a smaller one; individuals in large organizations tend to specialize, whereas in smaller organizations, individuals tend to "wear many hats" and interface across a much broader area. On agile projects, business analysts are expected to spend more time working across the continuum of the project - business process owners, developers, users, and testers, to name a few.
The opportunity for you, or a team member, is to recognize that you still have just as much value to add, but you will need to adapt to adding that value in a more collaborative way. In my opinion, this is actually a more natural, organic way of doing business, as specialization (IMHO) tends to be unnatural.
To use another analogy, think of the auto worker on the assembly line, working on a particular task all day, but never working collaboratively across the range of tasks required to assemble a car. Over times, auto companies have recognized that such specialization does not really result in a better, higher quality car, and thus they have reworked the assembly task to include collaborative teams that together are responsible for delivering a significant part of the car assembly. Less emphasis is placed on the task, and more on knowledge sharing and skills transfer.
I don't mean to equate the business analyst to an assembly plant worker, but I do think that the increase in collaboration and ownership of the deliverable has similarities.
Some say that the role of the business analyst, as it evolves from a specialty, is becoming a "generalizing specialist". Whatever exactly that means, I think it is fair to say that Agile teams require people with greater flexibility, greater discipline, and the willingness to work in an evolutionary manner. If you are steeped in the transitional approach to BA, adapting to this approach will take time and effort, but making the transition are not only necessary, but in the end the benefits far outweigh the effort.
For more reading on this topic, I suggest the article "Rethinking the Role of Business Analysts: Towards Agile Business Analysts?"