Creating Your Agile Business Analyst Role
Creating Your Agile Business Analyst Role
This is the first in a three-part series of blog posts addressing the biggest challenges faced by business analysts on agile teams.
As a business analysis consultant, trainer and coach, there is a single question that wins the prize for being most commonly asked:
“What is my role as a business analyst on an agile team?”
And I universally have bad news for them, and perhaps for you, dear reader.
There is no business analyst (BA) role on agile teams.
At least, not straight out of the box. Let’s look at the basic role-set in agile.
Roles in Agile
An agile environment consists, at minimum, of two participants: the customer and the developer. The customer has the need, and the developer has the means to fulfill it. It’s a match made in heaven.
But, since development is a lot of work, it usually takes a team of developers to build the product that the customer wants.
This is because most development teams have many times more customers than developers. Since each of these customers has diverse needs, characteristics and preferences, we end up needing a person (the product owner, or PO) to understand and coalesce this aggregate demand into a single product that the team can build. Cool.
And, since development teams will run into plenty of problems, many teams hire someone (the Scrum Master) to overcome obstacles, make sure that everyone knows what’s going on and interface with management.
So, let’s recap: customers, developers, product owners and Scrum Masters. While the last two are Scrum terms, even non-Scrum teams will have something similar.
And here we have the basic agile team, although it is sometimes expanded to include non-development roles as needed by our enterprises, such as testers, architects and even business analysts.
The Problem for Business Analysts
The problem is that, in agile, we business analysts are not responsible for our usual bread and butter, requirements. Instead, the implicit requirements of the customers are managed by the product owner, who is also responsible for creating written requirements, in the form of user stories, and conveying the understanding of the requirements to the development team.
This leaves business analysts to flounder. We end up helping the PO, development team and testers, but we have no direct responsibilities of our own.
This problem, as we’ve seen, is baked into the fundamentals of agile development in at least two ways.
First, the product owner role absorbs all responsibility for the business analysis work typically performed by BAs. However, this is not a business analysis role. Historically, product owners have come out of the product management function, and they have only performed analysis incidental to their positions. Product management professionals are focused on:
- Developing products that appeal to customers
- Monetizing that appeal. Certainly, business analysis will play a role in achieving these goals, but it takes a backseat.
Second, and more fundamentally, agile deprivileges team roles in general. In calling the team the “development team,” I’ve been fudging. It’s really a cross-functional team of professionals working together to build the product. The team includes developers, certainly, but also any other miscellaneous professionals needed to most effectively deliver a high-quality product.
Given the ad hoc nature of the situations that business analysts find themselves in, combined with the fact that we’re not completing backlog items ourselves, we find ourselves craving some understanding of our role on the team. Are we helping the PO to better understand his or her customer base? Are we floating from desk to desk helping the developers understand what needs to be built? What exactly are we supposed to be doing?
The Solution is Not to Find Your Role
The solution is not to try to figure out what our role is, but rather to create a role customized to the needs of our team, product owner and customers.
In working with numerous coaching clients, I’ve found a straightforward three-step process to most effectively help create a Business Analyst role that will make the biggest impact.
Step 1: Understand the (probably significant) Conflict Between the Values of Your Company and the Values of Agile
You probably didn't see this one coming. The fact is, no company is perfectly agile, not even the ones run by the people who invented agile. Every company has a culture, and every company is comprised of individuals with competing personal values, goals, beliefs, perspectives and egos, and these can all get in the way of collaboration.
The first step is to realistically and non-judgmentally understand what your company’s culture is. Until you understand that your company is not a perfect agile wonderland, you won't be in a position to design your role.
Step 2: Determine What Your Company Needs of You
Establish what not just your company, but also your team, your management, your product owner, your stakeholders and your customers need of you. Sure, what you yourself want to do is important, but it won't be sustainable or effective if you're not also meeting the needs of everyone else. We Business Analysts fortunately tend to be good at figuring out what our stakeholders need, but it's often harder to turn our analytical eye inwards.
Step 3: Design and Implement Your Role
For people like us, this is the fun part. In this step, you'll essentially put the techniques we use to create products to use in creating your role. No, you are not a product yourself; you're a human being. But there is a lot to learn (and leverage) by going through the same process.
By determining what specific features, values and benefits your role will possess, validating that role within your company, and implementing that role with an eye to regular fine-tuning and improvement, the BA role problem can be successfully overcome.
How about you? What role problems have you been facing either as a BA yourself or as someone working with them? Feel free to share your thoughts and experiences in the comments section below.
comments powered by Disqus