How to structure a BI team in agile/scrum

Question

I am about to take a role as a BI Product Owner, but there is some debate as to how to structure the team. Some of the articles and white papers discuss a BI 'team' but this causes me a few conceptual concerns. If I read people like Craig Larman (Large Scale Scrum) he advises creating a 'feature team' that works across the stack to create a coherent customer-centric product. That might include embedded BI to the extent that the customer wanted it and found it valuable. If so, the feature team might need BI skills, as well as their other cross functional skills to deliver, but at least they would understand the data since it would be part of their app.

However, BI is also a valuable internal product...using customer/app data to deliver customer insights, but also a whole range of internal operational issues that the customer might have no interest in. If you create a BI team centred on that 'product' then you have diverged from the customer-centric view (at least from a revenue generation point of view) but also you have a team that is not working right across the stack and doesn't work directly with the data.

Does anyone see that as a tension? Any thoughts/ideas/observations/resources?

All input gratefully received.

Ged

Answer 1

Some of the articles and white papers discuss a BI 'team' but this causes me a few conceptual concerns. If I read people like Craig Larman (Large Scale Scrum) he advises creating a 'feature team' that works across the stack to create a coherent customer-centric product.

What about having both?

On scaled frameworks such as SAFe, the guideline is to have, as you rightly mentioned, the feature team able to deliver value capable of delivering value with as less external dependencies as possible.

At the same time, SAFe understands that the knowledge amongst peers sharing same role and areas is not only important but critical for leveraging the multiple experiences and different types of practical knowledge available from a variety of people. How to address this? Creating Communities of Practice.

This way, you'll still be part of a client-centric feature team as PO, and at the same time constantly catching up with other BI POs in a product-centric community.

Answer 2

However, BI is also a valuable internal product

With this sentence you have answered your own question.

It is preferable to have feature teams rather than component teams, but not all products are externally facing. Many products are for internal consumption.

The way I like to define a product is something that provides business value and has distinct customers. Those customers can be external or internal to the organisation.

The tricky bit is defining what is a means to an end and what is a genuine product. For example:

Authentication component

Does not of itself deliver value. The authentication component is typically combined with other components and code to becomes a product that delivers business value.

BI sales report

This is an internal product as it delivers real business value to the sales team. They may use the information in the report to influence their decisions and so there is clear value and a defined customer.