Classic BA role in agile (scaled agile)?

Question

I work in an environment that has really embraced agile and I feel like when faced with a problem we double down on the framework. We're now in a position where we're going to have up to 5 teams working on the same thing, so we're planning on using the SAFe framework to accomplish this.

The product is quite large and my product owners and developers have all told me about the need for a business analyst. I'm wondering how and where this type or role fits in? Should I (I'm a manager) tell the team that it's not part of SAFe and that they themselves need to handle the whole backlog? Is a BA indicating that there's not enough business involvement?

Answer 1

The first thing I would do is make a distinction between the role of Business Analyst and the skill of Business Analysis. This may seem like an unimportant distinction now, but it will pay off long-term.

In Scrum, and in SAFe, there is an expectation that teams are engaged in uncovering and identifying the requirements. This absolutely requires the skill of business analysis and if the teams don't have that, it'll be challenging, as they've already identified. Here is where making that distinction will change actions though. There is only one way to add the role: hire/assign the person. However, there are many ways to add the skill. You can add a person with that skill, but you can also try to identify if people on some of the teams already have that skill. Perhaps one or two of your developers have BA experience and expertise. You can have a senior BA or two mentor the teams to help them learn to ask the right questions.

On complex projects, the teams are absolutely right that they need that skillset, but if they are looking for someone else to take on that responsibility so they don't have to, that can be very problematic for many reasons. To name a few:

1) the team still needs to understand the context, so that BA needs to re-explain everything after they understand it - information the team could have gotten first hand.

2) it creates a success bottleneck where the whole process hinges on one person (adds fragility to your process)

3) ever play whisper-down-the-alley in school? You're doing that with your BA with a complex project

4) it may (emphasis on may) be them setting up a fall guy if the project fails.

So, in conclusion, I'd help the team address the need for the business analysis skill but I would be very hesitant to solve that problem with a person who entirely owns that skill.

Answer 2

If you need a BA, then get a BA.

A Scrum team contains all the people necessary to deliver the product. If the skills of a business analyst are needed, then they should be added to the team.

I have found that in particularly complex domains (data science projects being an example) Product Owners often need some assistance with analysis. System analysts and business analysts are not uncommon in those kinds of environments.

If you bring in a BA who has not worked in a Scrum team before then you may need to be a little careful. They will need to be coached on Scrum and the Product Owner role. They will also need to work closely with the Product Owner to ensure there are no role/responsibility clashes.

One particularly successful Scrum team I worked with had a BA who worked very well with the Product Owner. Their coordination was so good that when the Product Owner went on holiday the BA would often step in to cover the Product Owner role.

Answer 3

In support of the other answers, I agree that requirements are supposed to come from your product owners (though not a big upfront list--just the initial steps). So if you need a BA also, I would question whom you are designating as the POs... especially since anyone insisting on that big upfront list is resisting the Agile mindset.

It might help to better define what we mean by "requirements." Sometimes product managers (as POs) can only determine user/customer requirements. They may need assistance translating those to language that makes sense to the technical teams, and often want help with technical and other internal requirements (like documentation). That's why for multi-team programs with multiple customers, I redefine the product manager as the "Customer" in the classic single-team Scrum model. Then I give each team its own PO per that model, but as a part-time role that combines the PO/BA responsibilities, usually taken by a former technical lead or BA. Among other benefits, this also eliminates resistance from product managers who feel they don't have time "to do my job and do the PO stuff too."

P.S. You probably already know this, but just in case: SAFe is not the only framework for scaling Agile across multiple teams (and I agree that it isn't fully Agile). If you haven't already, I hope you will look around for alternatives.