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.
