There are, for already some years, ongoing discussions about the understanding of what an “Agile Business Analyst” actually is, without a real consensus showing up. For some people, given the characteristics and competencies of a BA, the adjective “Agile” is redundant; for others, it is contradictory.

“Agile BA” looks like a pleonasm

In his post of 2014[i], Steve Blais gave an excellent overview of the disagreement that exists regarding the understanding of “Agile BA”. He also claimed that:

(…) a business analyst is, and really always has been agile.

Agility may be required in any environment and is not uniquely related to agile development; changes are inherently parts of a project; they may address different elements (irrational decisions, failures, occurring risks, invalid assumptions, new regulations, improved understanding, …) with frequencies more related to the environment than to the used project development approach.

Blais underlined that any good BA may recognize himself in the values of the Agile Manifesto and used this later to introduce the A.G.I.L.E. Business Analyst characteristics:

• Adaptability
• Goal orientation
• Innovation
• Leadership
• Empathy

Some of the Underlying competences of a Business Analyst as referenced in the BABOK 3rd ed. (e.g. behavioral characteristics, communication and interaction skills) also provide further elements in favor of this interpretation.

“Agile BA” looks like an oxymoron

Typically, agile practitioners used to state that there is no Business Analyst in their team because there is no need for it; there is no need for detailed documentation and no room for such a role.

Looking at the way agile teams work, we may observe that BA’s responsibilities (requirements elicitation & management; solutions evaluation …) are distributed between different predefined roles and the distribution depends on the method in place (eg.: In Scrum, the Scrum Master act as a facilitator, the Product Owner is responsible for requirements management, …). This looks good in theory but may not fully apply in practice; some team members may be lacking crucial BA skills and the introduction of a BA into the team may be an excellent response to this issue. The BA may also foster communication and requirements identification associated with environmental factors that could be out of reach for team members.

Any hope about an agreement on a definition?

We may wonder if one time we would come to a common definition of an Agile Business Analyst and if the Linkedin discussion referred by Steve Blais will ever end. We may have some doubts, especially so long the two schools of thought have different outlooks; the first one referring to the BA as a practitioner and the second one referring to it as a role.

In her blog post, after provision of some reasons for having a BA in an Agile Team, Bonna choi

concludes[ii]:

At the end of the day, the title doesn’t really matter. Each organization has its own terminology to call similar roles differently. What really matters is the kind of team dynamics needed to succeed with Agile.

While it may be difficult to get a shared definition of what an Agile Business Analyst is, we may identify Agile Business Analysis as the BA discipline commonly applied in agile development environments. The demand in this area is increasing and practitioners are developing, with more or less creativity, a large number of tools and techniques. Therefore, any organization (whatever its approach – agile or not), willing to identify, evaluate and adopt the most suitable tools or techniques, should definitely follow the latest trends in Agile Business Analysis.

[i] Blais, Steve (2014, January 21^st). What is an AGILE Business Analyst? Retrieved from https://www.batimes.com/steve-blais/what-is-an-agile-business-analyst.html

[ii] Choi, Bonna (2013, May 22^nd) Do we need a Business Analyst on an agile team? Retrieved from https://www.thoughtworks.com/insights/blog/do-we-need-business-analyst-agile-team