Out of many roles on an Agile team - developer, tester, project manager or product manager, the role of the business analyst is probably the one whose “existence” on the team is most frequently challenged. The role of a BA is often questioned, not the quality of work, but the “perceived” value delivered for the team - by clients. Frankly I’ve had a few identity crisis since I started working as an analyst on agile teams in 2006.
I’ve noticed that when a project shined with an analyst, two of the biggest benefits to the development teams have been:
Many seem to blindly believe that the business analysts' sole responsibility is to "write" stories. It may be true for traditional business analysts. But in the agile world, it is essential for the analyst to talk to the business stakeholders and establish communication mechanisms to understand why we are working on something before we develop it. And it is as essential for the analyst to then foster a shared understanding of this with the entire team. This entails a two-way communication flow between development and business.
On a distributed team of 20+ people project for a large retail client, our team was suffering from a poor understanding of the domain as a whole and why the work we are doing is required. As I spent a good amount of time understanding the domain myself in the beginning I decided to utilize 'lunch and learn' sessions to share my learnings using diagrams. It helped the team to connect the dots by understanding where each story fits in. As we continued to do this exercise, we started to have valuable conversations like 'this is why we need this story', 'we need to create more stories in this area', 'we need to get this story done before the rest of the stories for this feature' and so on. The impact of such conversations drove us to think what values each story was bringing in. Which in turn helps me to initiate the right conversations with the business which feed in our team’s understanding of the value of each story.
Teams can make faster decisions by getting answers quickly
With distributed teams, constantly changing market demands and complex tech stacks, product development is increasingly getting more complex, with an interplay of multiple systems and development teams. As the various business stakeholders communicate, rapid changes often result. The development team needs to be equipped with the fast flow of new information, so they can understand and influence changes.
Well, the Product owner can help with some of these, but often times the kind of conversations and questions the development team needs to know are more detailed than product owners can help with. As the product owner is often overseeing several projects and splits time in different locations, it's hard to be at the right place at the right time. Additionally, product owners focus on understanding the market and stakeholders while agile analysts understand the vision of the product and perform various activities in development team to reflect that vision into the product.
The agile analyst is someone who is at the center of such communications in agile teams and is dedicated to one development team. She communicates with various people by facilitating many agile rituals such as inception, iteration and story kickoff, estimation sessions, and numerous ad-hoc conversations. Her focus during such communications is to help the development team keep up-to-date with changes in customer priorities and to have their questions answered. This in turn helps them to proceed with their development work at a faster pace by making decisions based on accurate and well-understood data.
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. If there is someone who can deliver such works in your agile team, regardless of what their current job title is, your project has a great possibility to succeed. So instead of thinking whether you need a agile analyst in your team, let's think whether there is a person who drive such work in your team.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.