December 27, 2018
A frequently asked question when I am working with teams moving to Scrum is what is the role of business analyst role on a Scrum team. Usually it comes from someone with the title of business analysts but it may also come from the manager of the business analyst team. Immediately I know that there are going to be challenges.
Business analysts are generally smart, detailed oriented professionals who are frequently high-performers. They rarely have positional power so tend to build strong relationships and deep understanding of the nuances of the business to provide real value. They facilitate meetings and workshops and they are usually great at communicating their ideas and concepts like detailed process flows.
Before I dive into my arguments for why Business Analysts don’t really fit well on Scrum Teams, I’d like to point out that others have different opinions (and perhaps deeper expertise) on this subject. Kent McDonald is an agility expert and someone I’ve known for a number of years and he recently wrote the book, How to be an Agile Business Analyst. You can get a taste for Kent’s thoughts in this blog post What is an Agile Business Analyst. His primary focus is the thoughts and behaviors of the BA.
My biggest challenge with the business analysis in a transition to Scrum is that they frequently have difficulty acting as a development team member. I don’t know if they dislike the generalist role of team member or they like being special but either way they generally resist being part of the team. They like the concept of the specialist role and don’t want to be a scrum development team member responsible for getting all the work done.
As a reminder, in the Scrum Framework there are just 3 roles: product owner, development team member and scrum master. The last of those – development team member – is responsible for doing all the work to take backlog items to done within a sprint. There is no specific role for a business analyst.
In fact, eliminating specialist roles is a key part of moving to Scrum. The specialist roles create bottlenecks and inefficiencies as people are careful to spell out what is “my job” and what is not. Having people on a team who are unwilling to do certain jobs is suboptimal.
In addition, the way Business Analysts have traditionally worked is in conflict with the way Scrum teams work. The BA is often responsible to go out and gather requirements. They compile these into long, detailed documents and then they hand those off to developers. Yep, it’s the telephone game being played by adults. Putting a bunch of details into a document and handing it off to others is a surefire way to build the wrong thing.
They tell me proudly that they play the ‘translator’ role since they can speak to both the business and technology. Really? Since when don’t we expect all team members to speak to both business and technology?
On a development team in Scrum, everyone is expected to understand the business. And the remaining work is everyone’s job. Analysis, design, development and testing is the responsibility of the entire team. That doesn’t mean everyone is equally good at it or that it would be efficient for everyone to do every job. It is just a matter of ownership and teamwork.
Frequently the separation and specialness of the business analysts is reinforced by a business analyst manager who is responsible for all the BAs. This introduces differing loyalties, conflicting reporting lines and objectives and an even weaker commitment to the team success. The business analysis manager will usually be threatened by any suggestions about organizational changes.
I’ve seen some approaches that various organizations have tried to use to address the business analysts when moving to the Scrum Framework. Let’s look at 4 common anti-patterns of using business analysts in Scrum teams.
Let’s take a look at each of these in detail and explore why there might be problems with each of these.
Some organizations use the business analysts as a standin or proxy for a product owner. They either cannot find an appropriate product owner or the best person in the organization is too busy or not interested in the role. So they have a business analyst perform the role.
While it may provide a person who is knowledgeable and has the bandwidth, this approach usually results in subpar performance. The proxy product owner is not the real owner, they often sit in technology, they aren’t empowered and they frequently get overridden by others.
Another approach that I have seen used is to put the business analysts outside the development team and let them continue to operate as they always have. This includes them going out and collecting details on business needs.
Since they are using agile, they will write their long requirements in Jira as a faux user story. These user stories are then handed off to the team with no real connection or exposure to the stakeholders, users and subject matter experts. When questions come up, it is the BAs that go back to those experts to get answers. And that generally results in multiple trips since the BAs don’t always have the context to get the details correct on the first pass.
The problem here is the separateness. In this approach, responsibility for ‘grooming’ the backlog often falls on the BAs and they do this by themselves, without the team. There is no end to end ownership; the business analysts have no real skin in the game for team success. We have significant information loss whenever we have a handoff. And it gives the development team an excuse for not delivering – we are waiting for the BA to write the user story.
Some people became the “BA” because they knew a lot about how things worked in a particular area. Maybe they used to work in that area. The risk is that their knowledge may be out of date.
This approach fails for the same reasons as the previous; separateness and handoffs. In this approach, a single business analyst is responsible for maintaining alignment of multiple Scrum teams. They make sure that the backlog items have clearly defined dependencies and that each team is aware of what the other is working on.
By making the BA the glue, we remove an important direct communication channel between the two teams. The teams are perfectly capable of coordinating with each other if they are taught it or supported to do it.
This would seem like the best approach – just put the BA on the development team. And this can work, as long as we completely eliminate the BA role and title.
If the BAs on the team are able to still call themselves BAs, they are likely not integrating. They are going to just pick and choose and do the work that a BA would normally do. There may or may not be exactly the right amount of that BA work to be done on the team which creates an inefficiency.
You see it in the daily Scrum meeting for teams with that BA role on it. The BA will typically say something like, I don’t have any tasks on the board so just let me know if you need my help with anything. WTF???
As noted at the top, business analysts tend to be smart, detailed oriented and valuable. Having a business analyst on your team can be critical to your success. If they are properly positioned to add value.
Note that this article could just have easily been called, “What is the QA role in Scrum?” or “What is the PM role in Scrum”