The Agile Business Analyst!

Ever since the advent of the thing called "Agile", there have been debates about how a Business Analyst (BA), who used to work in the traditional model of project delivery, can add value in an Agile environment. However, the fact is that a BA's role always has been and is kind of "Agile" in nature, irrespective of Agile or waterfall or any other methodology/framework.

The reason is that business analysis isn't just a job title; it's a role, and it's adaptable. BAs always analyze and evaluate how their current skills and techniques can be adapted to the agile environment. BAs understand that not every technique is necessary for every project; it's more about determining which techniques need to be used, how, and when, based on the needs of a project. That's "agility" or "Being Agile." This reflects the agile mindset, which a well-informed BA has always embraced.

The Agile Mindset: Being an Agile BA means being flexible and adapting your methods to suit the project's specific needs. This includes guiding the team to achieve desired outcomes rather than just completing tasks, using established business analysis techniques to establish a “shared understanding” of the problem and driving the decision-making process. The Agile BA continuously gathers and incorporates user (stakeholder) feedback into product development, thereby delivering real customer "value."

How the presence of a BA in an Agile team can be beneficial?

In simple terms, an Agile team is expected to be self-sufficient, with each member capable of taking on various tasks. This raises a common question about the need for a dedicated BA in such a team. Yes, many agile-based guides (Ex: SCRUM Guide etc) do not have the dedicated role of a BA because an Agile team is a self-sufficient team that can do BA tasks as well. For example, a simple question customers ask is, "Why a dedicated BA is required when a Product Owner or a Senior Architect can do the required Business Analysis tasks?"

Well, the question is indeed valid.

In a typical agile setting, developers (or any relevant team member) are encouraged to communicate directly with customers to comprehend their needs rather than heavily relying on BAs for documenting requirements. But, in an Agile team too, various roles and skill sets are also required to successfully deliver customer value. One of the crucial roles is having individuals with strong analysis skills to carry out tasks such as discovering requirements, refining them, prioritising, elaborating, and delivering the solution—the stuff usually a BA does. Just because the team is Agile, we cannot skip such a necessary and critical "analysis" phase of a project. The title of the person performing these tasks (Whether he/she is a BA or not) is not as important as their ability to effectively analyse and contribute to the project. Hence, a “Business Analysis” as a task is very critical in Agile teams as well and a BA can become part of an Agile team to do these activities.

It is also true that in practical scenarios, developers (or any relevant team member) may find it challenging to engage with business users for requirement elicitation and other analysis-related tasks, making the BA a valuable resource, particularly for complex requirements that require analysis rather than just documentation.

Hence, a BA is also relevant in an agile setup, but his/her role may not be limited to just being a BA. A BA working in an agile team should possess/cultivate a good agile proficiency to contribute to the project. On the contrary, if a BA assumes the conventional role and serves as a mediator between the development team and the users, focusing mainly on requirement documentation and note-taking (while documentation is an important aspect), then this role may not align with the Agile principles.

A BA's roles and responsibilities in an Agile environment: Certainly, a BA's roles and responsibilities in an Agile environment could be a little different than those of a traditional environment because the Agile team is a set of people with the mindset of a "Self-sufficient and Self-organising team". In an agile setup, a BA should also gel well with team dynamics, possess the right mindset and deliver value accordingly.

Well-experienced BAs naturally have that entrepreneurial mindset that helps them resolve issues or problems. Their blend of skills spanning across technical, leadership, business, analytical, facilitation, and communication gives them a unique ability than anyone else in the team to work effectively across different functions and various customer hierarchies and apply their knowledge and skills in various areas making them valuable assets to any agile team.

Hence, while the title may be "Business Analyst," their contribution goes beyond a label, adding essential value to the team's success. In essence, when agile practices and business analysis work hand in hand, they deliver significant value to organizations. Rather than questioning their place in agile, the focus should be on maximizing collaboration for the benefit of the entire team.

What preparation does a BA need to do who is just transitioning to an Agile team?

Indeed, transitioning to an Agile environment from a traditional one involves recognizing the value of core business analysis practices. You may be used to hold workshops in the beginning for weeks and months. You might have great skills in creating flawless documentation and more. These skills are still valid but adapt your experience to the new "Agile" needs. This flexibility is very important.

Trim down unnecessary elements and consider alternatives to traditional documents. Communicate openly with your agile team to understand expectations and preferences. Explore whether wireframes, data models, use cases, or user stories work best. Collaborate to refine your approach and maximize value.

Have that “value” mindset.

Remember, current times need a "Value" mindset. Not just a "Delivery" mindset. That is, you should be able to demonstrate the value you delivered.