BA ROLE IN AN AGILE ENVIRONMENT
Posted By: admin
August 25th, 2011 10:32 am
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?
- On an agile team, processes, procedures, products, and associations, interactions will change. How BA should plan the work, deliver the product, represent requirements, share knowledge, interaction with their team and customers, managing and documenting changing requirements will be quite different from traditional, waterfall-style projects.
- In short, a BA will be part of a team of highly collaborative colleagues with a frantic focus on delivering value, negotiating value delivery in short cycles, and helping their business partners understand what they really need-not only up front but also as the product unfolds in small, usable chunks.
- Business analysts must turn down or let go control of the requirements, the customer relationship, and the usual requirements documentation. Why? It’s because it’s an agile team, they have to deliver working, valuable software every few weeks. And the BA, his/her team and customers don’t know exactly what the end product will be-not until they starts to build it, deliver it, and get feedback on it. That’s when one learns what the need really is.
- Even team roles can be ambiguous. Specifics may vary, but an agile team collaborates to deliver to a committed set of requirements. Each team member is willing, even eager, to do whatever it takes to make that happen, no matter what the official job responsibilities dictate.
- It’s likely that a BA is not the only one to elicit, analyse and specify requirements. The team is focused on delivering “shippable” software in short cycles (iterations), so your tasks may cross over to other activities that call on your skills, capacity, and interest. For example, BA is likely to identify-if not also create and execute-user acceptance tests with hands-on validation. Their soft skills and understanding of requirements dependencies make them a good candidate to facilitate planning workshops to define the product roadmap and release plans.
- An agile business analyst is no longer bound to large, complex requirements documentation and templates. Instead, they would be influencing their business partners and teams to rethink what kind of (and how much) documentation is needed. In this case, a BA may deliver documentation in small chunks along with the small, useful chunks of requirements that the team delivers in each iteration (often in the form of user stories). They can also pitch in to develop lightweight product, user, or support documentation.
- The work of a BA in an agile environment is both tactical and strategic: They need to grasp the big view (the product vision, roadmap, and release plans) while maintaining a firm footing in the now (the current iteration). Thus, they need the discipline and flexibility to operate in multiple modes (the “now” of the current iteration and the “later” of upcoming iterations).
What will the BA gain from working in this environment?
- Their work will be transparent. They would get better at estimating and working with their cross-functional teammates to reliably predict how much software the team can deliver in each iteration. The visibility of iteration planning, end-of-iteration demonstrations and retrospectives permit no hiding. The BA will find greater mastery by being openly accountable to their customer, the team, and themself.
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.