Challenges of Business Analysts Transitioning to an Agile Approach
The usage of the Agile methodology in software development projects has been steadily increasing over the last decade.
Its implementation either as a pure Agile or waterfall-Agile hybrid has driven many Business Analysts and project stakeholders to question: Do we really need the Business Analyst role when working with an Agile approach?
The Business Analyst and New Trends
A Business Analyst is not necessarily a fixed role or a mandatory project position executed by someone entitled a “Business Analyst.”
Business analysis began as an intrinsic set of tasks and competencies developed by people working closely with the business. These analytic persons usually worked either on software development projects, with the Developer gathering requirements and designing data structures based on defined needs, or even salespeople talking with business representatives to get an understanding of the underlying business needs.
With the increasing complexity of software development projects, the composition of the teams changed from generalization, with single roles, taking care of multiple tasks (Team Leader, Developer, Tester, etc.), to one of specialization. This gave way to the emergence of “specialist” roles and specific tasks assigned to each, making the collaborative work more formal. An example of this could be the existence of roles like Front-end Developers, Back-end Developers, Automation Testers, UI Designers, Database Administrators, and of course, a role specifically involved with business needs (or business requirements): the Business Analyst.
The BABOK Guide defines business analysis as “The set of tasks and techniques used to work as a liaison among stakeholders to understand the structure, policies, and operations of an organization and recommend solutions that enable the organization to achieve its goals.” In simple words, a Business Analyst is defined as anyone performing these business analysis activities.
Just like with other specialized roles, there are organizations that act as bodies of knowledge of common business analysis concepts, techniques, and processes. Examples of this could be IIBA and PMI.
Over time, the Business Analyst role became visible and specific within the Software Development Life-cycle. On typical Waterfall methodology projects, the Business Analyst was usually entitled to gather the business needs (requirements) and deal with communication, requirements definition, business domain knowledge, and in general, all the business-related tasks not related to budgeting or high-level planning.
With the emergence of new software development approaches, the Business Analyst needed to refresh and adapt their own role to keep pace with the latest industry trends.
Why do Business Analysts Need to Adapt and Adopt Agile?
With the increasing adoption of the Agile approach on projects, people executing the analysis work, either those clearly identified and certified as business analysis professionals or team members responsible for the business analysis work, started planning on how to better approach this changing way of doing things and how to engage it.
On traditional Waterfall projects, even though the analysis work is not necessarily executed at a fixed phase, it is true that the Business Analyst role is clearly identified as that person or group responsible for requirements-related work.
Often, in organizations transitioning projects from a waterfall approach to an Agile approach, Business Analysts are indeed included as part of the process. However, it can be that their actual role or tasks are not really defined, relying on them the mission to figure out how they will fit into the process.
Common Challenges from a Waterfall to Agile Approach
Just like the common misconception of thinking that Agile does not require any documentation or testing because it is aimed to deliver value quickly, it is also often thought that since the Business Analyst role is not defined in Agile, then we really don’t need business analysis as part of the process. But this is not necessarily true. After all, not having a Business Analyst role should not mean that business analysis should not be taken care of.
Business analysis remains a critical task for an Agile project. After all, it involves assessing the value we are delivering. Also, common concerns such as business policies, government regulations, and business processes will still be around and will impact projects, no matter the waterfall or agile approach.
Not having a defined role for a Business Analyst doesn’t mean we don’t need to consider these anymore.
On a traditional Waterfall shaped project, the classic workflow for business analysis work was what the business needs. The requirements should be defined, confirmed, and documented before continuing with downstream processes such as design, development, testing, etc.
This changed with the introduction of Agile since work needs to be done in rapid iterations, meaning we do not need to have the whole business requirements identified or defined from the beginning.
The modern Business Analyst should have a smooth adaptation to the Agile world; this is due to the already iterative and concurrent nature of the current business analysis tasks and techniques. As referred by the BABOK guide about the distinct business analysis knowledge areas, “Business Analysts are likely to perform tasks… in a rapid succession, iteratively, or simultaneously.”
Although there is no Business Analyst role defined at the common Agile team roles, there is one where the Business Analyst usually finds fit if a more formal title is at hand: the product owner.
The product owner has two main goals:
- Represent the needs of the stakeholders to the Agile team. It is the first source of domain information.
- Represent the Agile teamwork to the stakeholders.
There are several common aspects when we look at the product owner characteristics against Business Analyst:
- Communication: Acts as a communication proxy between the business and the Agile team.
- Requirements: The product owner is responsible for requirements prioritization and is in charge of providing requirements details to the team.
- Business analysis skills: They need to have common BA skills such as stakeholder need identification, priority negotiation and effective communication skills with the Developers to ensure requirements are correctly implemented.
What Should a Business Analyst do to Overcome Challenges and be Effective in Agile?
It is in the nature of seasoned Business Analysts to keep improving their skills and their knowledge. Just the same as businesses keep changing and evolving, a Business Analyst should evolve and embrace new ways to work.
Furthermore, it is key for the Business Analyst to understand that Agile teams are usually formed of generalizing specialists.
Generalizing specialists have more than one technical specialty, enabling them to contribute directly to the team. They usually combine several technical and domain knowledge skills.
It is worth mentioning that Agile teams are “whole teams”, meaning that we have all of the required skills within the team. Agile teams should not rely on external experts or teams of experts to get the work done.
As such, Business Analysts taking the role of product owners should also focus on becoming a generalizing specialist by combining the already acquired business analysis skills with knowledge of one or more technical domain areas as required so they become part of the “whole team.”
Bibliography
The BABOK guide – IIBA
The Agile manifesto – the Agile Alliance
“Beyond Requirements: Analysis with an Agile Mindset” – McDonald, Kent J. (ISBN-13: 978-0321834553)
Agile Extension to the BABOK®Guide – IIBA
