The agile flaw and the BA to the rescue In the agile world there is a lot of talk about the business analyst being superfluous, unnecessary in an approach that calls for the development team to relate directly with the customer. The business analyst is considered on more layer of miscommunication between the problem and solution.

One basic flaw in the agile approaches is their dependence on the customer for all direction, evaluation, and approval. This is good from a theoretical perspective and clearly follows the expectation that IT is driven by the business. However, there is a somewhat naïve expectation that the business will provide the appropriate customer and that the business knows what it wants. The mitigation that agilists use to accommodate the customer not knowing what they want is that the risk of delivering the wrong solution or having the customer change his mind after delivery is small since the timeframe for delivery is small. What happens though when the customer does not realize the problem is not getting solved until four iterations’ have passed? That is a big expense. The agilists say, “it’s the customer’s fault for not knowing and not evaluating correctly. We did our job right.” And they are right. But that still does not resolve the issue. What is needed is someone or some process – and here, of course, we are talking about the business analyst and the business analyst process – to assist the customer in defining the problem and what is needed to solve it before the Scrum sprints begin. Then the agile approach makes exquisite sense. When the business analyst can work with the business and the assigned customer, and the emphasis is on “with” rather than “for” or “on behalf of”, the customer is better able to understand the issues around the business problem and also how to express those issues to the development team. The risk of heading down the wrong solution path is minimized.  ¶ 6:05 AM