Business Analyst in Large Scale Scrum

Over the last weeks I’ve been working on a paper about the role of a Business Analysts within Large Scale Scrum, and I thought I’d write a little post on it too, here it goes.

On the website of the IIBA you can find their definition of a Business Analyst.

liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals

www.iiba.org

In a Large Scale Scrum organization this definition often results in Business Analysts working as a liaison between stakeholder and the teams. And this liaison role turns out not to be very effective at scale.

A business analyst is not the same as a Product Owner

We know that there is only 1 Product Owner for a product, see the Scrum Guide; but in Large Scale Scrum adoptions, you often see lots of Product Owners although only 1 product is being developed. You can expect to see that each Development Team has its own unique Product Owner (PO) and that a BA plays the PO role. This is an understandable and easy step to take for an organisation; all you have to do is change the role name from BA to PO.

All these BAs stay a liaison between the Development Teams and the customers. And the liaison role introduces unnecessary hand-off; documentation; information scatter; and poor customer understanding by the teams – see my paper Copy Paste Scaling for more details on this.

A BA can play the role of a PO if she has the right market understanding, skills and mandate; but it is generally a bad idea in Large Scale Scrum to have a separate BA play the role of PO for each Development Team. Instead keep it simple, have 1 PO and create true cross-functional teams. 

From recomending to developing

A BA with a responsibility for analysis alone does not work anymore and the reason is simple: Analysis is not something that adds customer value on its own; it is just one of the activities in the end-to-end value chain. So you would like to avoid locally optimising Business Analysis. Instead you would like a BA to be responsible for delivering working product and that they directly work on validation and implementation of the product.

These days it is essential to validate assumptions quickly. Answers to questions like:

  • Are we solving the right problem?;
  • are we solving the problem correctly?;
  • and does the solution add enough value to us?

 requires frequent feedback. 

Therefore, you would like to have a BA as one of the Development Team members, just like a programmer, tester or domain expert are too. Now, the BA can use its expertise, which is essential for success, more effective and help to optimize the whole of product development.

As a Development Team member the BA:

  • keeps a focus on the end result;
  • can see if ides actually work;
  • can adjust rapidly if ideas do not work;
  • can easily share his expertise with the rest of the Development Team;
  • and can take the lead during refinement sessions. 

So, if you want to optimise for speed, agility and learning, it is probably better to have a BA be part of your Development Team and not be a fake Product Owner.