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.
a 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 goalswww.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 recommending 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.