What to do with Business Analysts in a Scrum environment?

Question

In a company, they have decided to adopt scrum about a year ago, and they still have BAs (Business Analysts), who are separated from the Scrum teams. How it works is:

• The BA will get the specs for the client (as usual) and will then prepare documents and BRDs (Business Requirements Documents).
• The client will sign off these documents.
• They will hand over to the PO (Product Owner). The PO will prepare stories and then then the typical Scrum process will take its course.

Typically, the BAs will be quite ahead of the process, about 3-6 months ahead. These documents once they are signed-off by the client (and product) they will hibernate, until the PO has space to take them in.

Albeit, this process is heavy, the company doesn't know any better. What are better ways to improve the process, move it closer to agile, and improve the heavy status quo?

Notes

• PO's interactions are with the BAs, the development teams and the product.
• The BAs have little to no involvement and communication to the development team, as that's "low level" and they "don't need to be that close".

Answer 1

TLDR

They're a bunch of oxygen thieves who are holding you back. Either make them into useful people, get rid of them or have them guard the bees.

Same point with more nuance (arguably):

The BAs are essentially doing what would the job of the product owner and the customer should be doing. Potentially the preparation of stories is too much work for your PO to handle and they need extra help. Clearly they don't need this much help, as you have a massive amount of inventory.

I mean inventory in the lean sense. Work in progress that cost time to make, costs time to keep track of, and will probably have decayed into uselessness by the time you need it. This last one sounds particularly true, as I imagine your PO spends a lot of time reworking out-of-date specifications (or at least I hope they do). Additionally, this massive pile of over-worked specs kind of makes a joke out of the idea of being responsive to change, and erects a barrier (in the time) between the customer and the developer.

These BAs are getting in the way of communication between developers and the customer. Traditional software development has a lot of gatekeepers that separate the developers (and other "low level" minions from the customers). One of the key values of agile is a rejection of this, communication is key. I've had BAs who see themselves as owners of the communication between the customer and developers, and it just adds confusion and delays feedback. The fact that additionally your BAs won't talk to develops is just appalling.

So what can you do with these people? Perhaps there's something your team actually needs that the BAs are capable of, like testing or directly assisting your PO?

That's easier said than done. How do we start being more effective within the current status quo now? Here are a few of my ideas. I've had a few guesses at what problems the BAs are causing, but spend some time with your team doing this, and come up with your own solutions.

The work is out of date and not valuable: There's nothing wrong with ignoring or throwing out someone's contribution if it isn't a positive one. Make your your PO + development team does rework needed in communication with the customer.

Lack of communication with the customer: Circumvent the BAs during the rework and talk straight to the customer.

Lack of "agility": Use this communication to ensure that the customer can come straight to you guys with the stuff they actually want done urgently.

Answer 2

I'd argue that the role of the BA in modern scrum / agile is to expose root requirements and police value. This isn't something that can happen in a vacuum; to execute, the BA needs to be a 3rd voice in the conversation between Product Owner and Developer. To elaborate:

1. Expose root requirements: Product owners are going to want to give you solutions when your developers need the problems that they are to solve. Moving the PO-Dev conversation from "I need this button" to "I need a way to solve this problem" is where the BA adds value.

2. Police value: When POs/Devs are in total sync about the problem and the solution, it is on the BA to trace a business need and ensure the 'juice is worth the squeeze' (often within the context of a project). This is one of the hardest parts of being an agile BA - calling out features that are out of scope or that suffer from questionable ROI.

This is a unique role that adds value in very different ways from a Dev, PO or PM. Of course in many development environments the responsibilities of the agile BA will be absorbed by these roles, but that in no way means that BAs are vestigial. Just because a general contractor does all the brickwork, electrical and plumbing work in a project, it does not mean that masons, electricians and plumbers are obsolete and should look to transition roles.

Answer 3

My suggestion is to get the PO involved in the process sooner. Instead of waiting 3-6 months, get the PO involved with the BAs as soon as the analysis/documentation is ready. Before it is taken to the client.

The PO can then take them to the developers, with the understanding that the requirements are still up in the air. This could also allow early discovery of issues; such as a requirement that is simply technologically impossible.

Answer 4

This kind of "agile" development is one reason why agile developing is postulated as dead (even by those guys who came up with the Manifesto for Agile Software Development) (1).

From my point of view the biggest problem in your constellation is the distance to the client. Agile development is all about involving the client as soon as possible.

So first of all, the PO has to establish an direct/unfiltered communication channel to the client - right from the project start. At best this should be a direct communication or at least a unfiltered communication through the BAs. It will not work when the BAs organizing some meetings/workshops behind closed doors and the PO gets a (memory) protocol at best.

Besides that, the PO has to involve the client after/before every Sprint. He has to ask for and even kindly demand feedback from the client, discuss new or changed requirements based on the current results and decide the upcoming/recent user stories. Usually, the client doesn't have the time to get that much involved. The PO has to make him understand that his contribution is essential to achieving the defined project goals.

Additionally, make sure that the client becomes interested in the project development (and not just in the final product). So make sure every Sprint provides a new business value for the client which is up for discussion.

Once the client get hooked, don't forget as PO you have to coordinate changes/requirements for example by establishing a working change management process.

Finally, don't focus that much on the heavy process your company has. Remember, persons/individuals are more important than every process in an agile development.

Answer 5

TL;DR

• Integrate BAs into Development Team
• Recruit them into a PO SWOT team
• Ask them to evangelize the product
• Offer a role shift or a career transition ;)

---

Business Analyst is the new Developer

Some BA's may do very well taking on the Development Team member role. If they were involved in constructing/gathering a requirement they could verify/test that a solution is fit for purpose. Before that, they could pair or mob during the actual coding to guide an implementation of a feature to be fit for purpose with great efficiency. They could also help produce any artifacts e.g. documentation that are part of the Definition of "Done" for a Product Backlog item. Remember, just because you can't program (yet) doesn't mean you can't be a developer in Scrum :D.

Product Owner SWOT Team

A Product Owner needs support to do their job well. Consider recruiting some of those analysts into a team dedicated to finding new value for the product, constructing product experiments (read: new features that get verified scientifically), scouting out competitor threats, and in general provide marketplace analysis. A product owner well supported in this way makes decisions scientifically. Without it, the PO may be left gazing into a crystal ball for predictions. In short, you want Isaac Newton not Nostradamus. Slide deck credit goes to Mark Noneman and Madison Henry Group.

The Power of [Product] Compels You!

Even the best products may need a bit of talking up. This is not advertising per se but rather advocacy. They could produce documentation artifacts e.g. blog updates, how to articles, video demo's, or interact directly with customers who are having trouble using or understanding the product. Really any such thing that is necessary for a product or feature to be well utilized.

So What Would You Say...Ya Do Here?

If it's unclear that they are bringing value in their current role, calmly assure them that their position is safe but their role isn't. Kindly ask them to consider one of the above roles or collaborate with them to create a new way they can either assist or be part of a Scrum team. If they don't budge, it may be time to assist them with a career transition if you catch my drift.