Search This Blog

Thursday, March 7, 2013

The business analyst in agile software development, part 2: What is your value??

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.

Wednesday, March 6, 2013

The Business Analyst in Agile Software Development Part 1

I am getting a lot of questions and concerns from business analysts about how business analysts fit into the agile world that appears to be taking over software development, and just about every other thing.  My local grocery store has a sign that says “agile grocery shopping”. I’m not sure exactly what that means. I’ve been afraid to go in and try it.
Because of the interest and uncertainty, I thought I’d do a few blogs on agile and the business analyst, looking at the issue from a variety of different perspectives, both good and bad.
Here is the bottom line according to the agile zealots:  there is no business analyst in agile.  Wow!  Is that harsh! 
I have had many long conversations over the years with agile adherents such as Ron Jeffries, Scott Ambler, and Steve Gordon among others about the subject of business analysts in agile software development and the message was always clear: there is no need of business analysts in agile software development. Why? Because the theory is that the developers will talk directly to the customer, in the form of a product owner or a customer on-site, and need no intermediaries.  To the ardent agilists, a business analyst is just an impediment who offers no value to the transaction. Why would a developer need someone to translate what the business is saying when the developer can talk directly to the business person and not run the risk of miscommunication?
This is not really meant to be a pejorative condemnation of business analysts by these stalwart gurus, although many developers do not have a positive view of the role of business analyst which I will address in my next blog. 
The issue is what does a business analyst do when faced with the situation of the developers and others suggesting that their value to the software development effort is negligible and their services as business analyst are no longer needed?  I have four possible solutions and a bit of positive news in the forthcoming blogs.