Whenever we speak or mention about a BAÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s role, the first thing that comes to everyoneÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s mind is the SDLC and that too particularly in context to the conventional Waterfall methodology. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). In this approach, the business analyst has to gather and document requirements and business rules upfront prior to the development phase. In this jet age where everything and everyone is expected to produce results as fast as possible and keeping in mind, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles.
Ãƒâ€šÃ‚Â Some believe that the Business Analyst role is not needed with the agile approach where as some strongly feel that, regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed as even though the designers/developers are doing their job well, they still have to worry about their expanded role of directly interacting /interfacing with the stakeholders, which if, in the presence of a BA would certainly not be the case. In spite of several approaches present for solution development, one thing that has not changed, regardless of the SDLC used, that the functions that roles provide. In an agile case, BA functions are absorbed by members of the software development team at some risk.
However the question that strikes in everybodyÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s mind is – “Is there a need for a business analyst role in an agile software development team?” The debate on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach has always been a debatable topic in the BA community. The role of a BA in an agile environment is definitely going to be different from that of BA in a waterfall environment.
Let us try and analyse what changes can a Business Analyst expect in an agile environment?
What will the BA gain from working in this environment?
Whenever solution features are being defined, prioritized, analysed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.