Let’s talk about where the somewhat negative attitude toward business analysts in the agile community comes from. Please note that the attitude is changing for the better, and we’ll talk about that later.
The knock on business analysts is because of the observed behavior of business analysts who perceive their role as one of ‘collecting requirements’ from the stakeholders. As such they facilitate a meeting and ask the stakeholders in the meeting what they want. The stakeholders respond, and the business analyst writes the requests down as dictated, rewrites the requests into the formal organization-defined business requirements document, get it approved, and pass it on to the developers. The developers, seeing this, wonder why they can’t simply ask the stakeholders the same question, get the same set of requirements, and start working on them without the interim steps.
As hopefully can be seen, the problem is that the business analyst in the scenario does not really add any value to the transaction between the stakeholder and the developer. Perhaps the business analyst might point out that he or she provided translator services by translating business-speak into tech-speak. The agile developers say that they can just as easily ask for an explanation of any terms or jargon they do not understand, and there will be less chance that of mistranslation. Again, the question is what value is added?
As a business analyst, in general, not just in terms of agile, we have to know what our value is to the organization, and also to all the parties. What is our value to the stakeholder? What is our value to the solution team? This is not an insignificant question. Many business analysts assume that just because they are a business analyst and they are assigned to a project everyone will understand the value they bring. After all, no one questions the value a Java developer brings to the project. Remember, though, that the profession of business analyst is very new and as a profession we are still struggling to define our place in the scheme of things. So if we cannot come up with a universal definition of what a business analyst does (other than practice business analysis) how can we expect that everyone else will share a common definition?
Even a Java developer has different value on different projects and perhaps even at different times during a project. While the senior line manager is defining the business case, the Java developer may have limited value, for example. If the primary bulk of the code is being written in C#, the Java developer has less value than the C# developer. And so forth.
The issue is, what is your value to the organization? Can you state it in unequivocal terms? Can you state it so the organization management not only understands but agrees if you were called upon to do so?
Can you state the value you are adding to the project? Can you state it in such a way as to gain accordance from the team and stakeholders involved with the project? Can you defend your value statement if someone does not agree (as in the statement of “I add value by translating terminology” above).
Once you can define the value you add to the project and to the developers then you will be in a position that any software development approach, even agile, cannot unseat you because they cannot replace your value with anyone but you (or some other equally qualified business analyst). And you don’t have to worry about being booted off the agile island.
I will give you some time to think about your answer and provide a few suggestions later. In the meantime, in the next installment I will address the issue of it being too late. When the die is already cast and the business analyst role is already removed from the software development process, what do you do? Where do you go? Answers next.