Scrum when each member has their own product

Question

I work in a team of 15 that implements scrum (as well as we can). Each person in the team has multiple products, that only they work on, and each of those products are unrelated to any other product on the team. However, put everything into one backlog to facilitate scrum.

We have a scrum master that leads the team, but no product owner (because there are so many products all unrelated, each member is responsible for their own backlogs).

We have noticed in daily stand ups that while it's good to catch up, whenever you are not speaking, the products you are hearing about from other members have nothing to do with your own work, and there isn't a single product that has more than one member working on it.

I would like to ask if it sounds like we should even be using scrum? If so - are there any ways we can make our standups and sprints more relevant for each member?

Thanks

Answer 1

It seems that you're using some Scrum characteristics but not the Framework. There are some gaps in your description that I'm curious about:

• Who manages the backlog and sets priorities?
• Do you do plannings, reviews and retrospectives?

It's really hard for me to imagine how it would be a planning meeting for a group of people where each person works in a different product.

So, answering your questions:

it sounds like we should even be using scrum?

It doesn't. You could ask your managers why are you "using Scrum", if it's just because it's a trend then you could try something else. Also, I think it would be easier for you guys to filter the backlog based on each one's product, and start using a Kanban board to follow-up progress. It's simpler and it fits for teams and "solo teams" :D

are there any ways we can make our standups and sprints more relevant for each member?

You can define time-boxes for releasing your increments and call it a Sprint, it won't be in the Scrum perspective but it's a way to organize deliveries.

I would keep the standup meetings as you have some relation between what you call "different products", mostly because if they are pragmatic the team can always benefit from it, but I would try to see which products would be really involved in each of the standup meetings to avoid taking people time to listen to things they aren't involved.

Answer 2

It sounds like there are a few things at play here:

Product vs applications vs Project

That many products sounds abnormal - certainly difficult to maintain. Usually when I see people say they have so many products, they really mean applications or projects. There are two things I usually find helpful in discussing a product: first, what does the customer think? Would your customer say that your product is data analysis, or cardiovascular data analysis? And second, it your approach similar between the different types of data analysis. They don't have to be the exact same, but similarities in approach mean that improvements in one area can carry over to others if you treat them as 1 (or fewer) products). Think of Microsoft Office. Word, Excel, and Powerpoint all work very differently, but there are all ways to create documents of some sort or another and treating them like one product has huge advantages.

The Benefit of Teams

What you describe doesn't sound like a team. It sounds like a group of people who happen to share an office. A proper team can benefit from more flexibility as well as increased productivity. For example, if more work comes in for one type of work than another, a team can pivot their attention to field that work, but the setup you describe must force those projects to wait. Also, most work that a team takes on has some forms of repeat work between tasks. Often times teams working together can handle this work more efficiently so they gain higher productivity.

Where Teams Don't Work

If the work is radically divergent, it may be that each type of work requires complete attention and all of a person's time to keep up with developments in that type of work. This is very rare - usually only effecting bleeding edge research, but I don't know what kind of work you're in, so maybe this applies.

Using Scrum

Scrum is designed to help teams solve complex problems and iteratively develop products. It isn't that Scrum won't work for other things, but this is what it really excels at. If this isn't what you are doing, there may be better approaches for you.

Answer 3

That is not working within the Scrum framework, but Scrum In Name Only (SINO).

Scrum is a framework for developing, delivering, and sustaining complex products.

When choosing to share people across multiple projects, efforts, products while calling it a team, the Scrum framework would be an improper force-fit. One way that ineffectiveness and inefficiency is being exposed is what you call the daily stand up, probably really a traditional status report.

This classical mismanagement may continue with its costs ignored. A better alternative is working toward changing the approach to a more dedicated personnel model, and change can be very challenging.

Answer 4

If the "products" (you can name it projects or whatever is suitable for you) are not related then there is no need to have a stand up together because the status is not important to the others, and in your case, you actually are not one team. One stand up meeting will distract the ones who are not interested in the information being shared in the stand up.

It is better to have the stand up with the related team members only to keep focusing on the project and the status of that project (milestones, issues, achievement... etc.) rather than to involve everyone.