As organizations attempt to operate in an agile manner, many business analysts wonder where they fit.
Here are the most common roles I see business analysts playing in agile organizations. The main factors in determining where you end up include:
- Your background, experience, and interests
- The nature of the product you are working on (is it a product for sale, is it a digital product such as a website or mobile app, or is it an internal facing enterprise product)
- How extensive the agile mindset is in your organization. The quick way to figure that out is if your organization generally seems to act in an agile fashion, but doesn’t feel the need to talk about it much, it’s probably pretty far along.
Yes Virginia, you can be a business analyst on an agile team.
A common model is where there is both a product owner and business analyst that work on the same team. This model often occurs where the product owner decides what items should exist on the backlog and in what order.
The business analyst applies their understanding of the stakeholders and the systems involved to describe backlog items to the point where the team finds them ready. In these cases the business analyst often works closely with the team to answer questions and provide clarification on the backlog items. In effect, the business analysts focus is build shared understanding.
You’ll see this model most often on teams working on enterprise products for internal use, such as POS, CRM, and Data Warehouse. The business analyst is there to bring order to the complicated nature of all the impacted stakeholders and systems. This model is also prevalent when there are multiple teams working on a complicated product.
Product ownerships consists of three things:
- Focus everyone on outcome over output.
- Build and maintain shared understanding
- Make sure decisions get made
Good BA’s should do the first two things as a matter of course.
In order for a business analyst to be effective as a product owner, not only do they need to continue to do the first two things, they also need to be able to make decisions.
In some cases business analysts aren’t in a position to make decisions themselves. This generally occurs when they are dealing with several stakeholders who don’t own the internal product, but have considerable say in what it looks like.
If you as a business analyst do your job right, your development team will not experience a difference. They won’t experience interruptions due to delays in decision making, they just may not have insight into how those decisions got made.
When your team works on a software product for sale to actual customers, or on a customer facing digital product (think websites and mobile apps) you may see people filling this role, or you may fill this role yourself.
Product managers spend most of their time understanding the needs of their customers, working with their team to craft experiments to identify good solutions, and putting together a broad ranging plan to figure out how to meet those needs with the solutions they came up with.
Depending on the size of the organization, a single person may split their attention between their customers (product management) and the development team (product ownership) or they may focus primarily on their customers and work closely with someone else whose primary focus is the team.
Product managers tend to have definite decision making responsibilities – the prime one being to continuously determine whether to continue, change, or cancel work on their product.
The equivalent to a product manager in an IT setting where most of the work is on software assets intended for use inside an organization is a portfolio manager.
The portfolio manager makes continue-change-cancel decisions on initiatives guided by organizational strategy and the needs of stakeholders, which are interned influenced by what needs to happen in to satisfy customers’ needs.
Product managers have to deal with a great deal of uncertainty as to whether customers will buy, or use, their products. Portfolio managers have to deal with the complicated nature of organizations to make sure all the right pieces are put in place in an effective manner. Someone filling both roles is well served if they have a strong business analysis background.
I’ve also seen business analysts slide into the role of coach (scrum master) because they have good facilitation skills and are able to work through team dynamics issues. This situation is a good indication that people should fill the roles that their experiences and skills prepare them for, not solely based on their job title.
And of course, that does not preclude someone with a business analyst background taking any one of many leadership roles in the organization because of their understanding of how the business works, ability to facilitate discussions between a wide range of backgrounds, and the ability to communicate effectively.
Who knows, you may even start your own company. I’ve seen it happen.
Project Management is Output Focused
You may see many business analysts working as project managers, but I didn’t list them in the opportunities above because while it may happen, I’m not convinced that it’s a trend that is prevalent in agile organizations. The main reason? Agile organizations tend to want to make decisions based on outcomes and look to product people to lead the charge in that. Project managers are inherently output focused.
So while business analyst used to be viewed as a stepping stone for project manager, I’m not sure that should still be the case.
My original thoughts on the topic
I see this question “What is the Role of a Business Analyst in Agile?” asked quite a bit. I’d like to suggest that rewording the question may be a bit more instructive. Instead of wondering what is the role of a business analyst in agile, you may want to ask the question “how can people who have filled the role of business analysts in other settings contribute effectively in an agile setting”?
Putting Business Analysis in the perspective of Product Ownership
People who help their organizations determine the right things to deliver can have a variety of job titles and can fill a variety of roles. The rise of agile approaches in general and Scrum in particular added another role to the list – Product Owner. As with everything else related to agile, the nature of the Product Owner role, and whether it is needed at all, depends a great deal on context. As teams discover this, it leads to some common questions:
- What do Product Owners Really Do?
- Where in the organization do they fit?
- Do we even need Product Owners?
In the series of posts starting with this one I took a closer look at the Product Owner role in an attempt to answer those question and hopefully others as well.
Business Analysts are Product People Too.
Here is an exploration of product people, those folks involved with product development and IT work that concentrate on determining the right things to deliver. The four roles in particular I include in the category of product people are product manager, business analyst, user experience designer, and product owner. Let’s take a look at each of these roles.
The Great Debate?
The latest debate is product manager vs product owner. Whatever you think of the debate, I think it’s a good sign that at least it’s happening.
To me it’s an indication that teams are starting to care about the product aspect of things.
Several experts, practitioners, and pontificators have weighed in on this topic, so I thought it would be interesting to compile the various perspectives on the product manager vs product owner debate. For each post, I note the author, a little bit about them, and the gist of their perspective. I’ve tried to include those that I agree with and those that I don’t.