Best practices for a Scrum Master with a team doing a lot of little products/projects

What situation? What is the problem with events? What is the situation you need to handle, as a Scrum Master?

I find myself in the exact same situation (with the addition that the "other" projects the team is working on are not done with Scrum), so I might list a few examples of concrete problems that I encounter. Jack Bakker can then confirm whether he has the same or other problems.

I currently see the fact that most members of my team can commit only 1-2 days of work / week to the project as the #1 challenge:

1. In this setting, even the 15-minutes daily scrum makes little sense, because it eats up a too big percentage of their time and because they might not have worked at all on the project "in the last 24 hours". The pragmatic solution was to turn it into a 20-minutes "weekly catch-up", which, looking at the Scrum guide, automatically disqualifies the project from being considered "Scrum"
2. The values of focus and commitment are very hard to implement, because, even if the team members have a very high willingness / commitment to achieve the product goal, their mind and calendar are also occupied by all the "other things they have to do for the other projects"
3. Having people working in parallel on different projects, in different settings and with different stakeholders increases the likelihood of running into logistical bottlenecks regarding the Scrum events. In other words: how can you set a fixed "place and time" for all Sprint reviews, when the weekly agenda of each team member and stakeholder looks so differently? (I work only Monday Tuesday vs. I work every morning vs. I need to be flexible and reactive for another projects and can't fully commit to regular events  etc.)
4. When people work a relative small percentage on a project, they will not necessarily all work at the same time on the project. So, if a team member need support from another one, he / she might be stuck 2-3 days until the colleague is back on the project
5. With a team new to Scrum, the learning period will obviously be much longer, which can lead to more frustration and misunderstandings

My personal conclusion is that Scrum can only be efficiently utilized in contexts where the whole team can dedicate all (or close to all) its working time to reaching the product goal of your product. In cases like mine, we can only do "Scrum-inspired" and be careful that this does become some kind of Scrumbut.

But I'd be happy to hear other stories and opinions!

Thank you for your answers.

The situation as it is right now, isn’t really a problem, but we’re looking in to ways to optimize it. A Sprint Review with the whole team for example isn’t really feasible, same for the Retro as they don’t work together on the same project. (To be clear, this team has 20+ small projects.)

I was thinking to split the team in 4 'official' sub teams and let them do a lot of pair programming so knowledge is transferred and less fragmented. That would mean we have to do 4 retrospectives every sprint with the sub teams and perhaps once every two months with the whole team. Not ideal but better than no retrospectives and review meetings.

Or perhaps we should switch the whole team to Kanban or Scrumban. Also meaning we should do a lot of knowledge transfer. Probably much more than with the sub teams.

I know we’re working against the Scrum rules right now, but real life has a lot of grey zones and the key here is to make the best of situation. I’m pretty sure we’re not the first facing this situation and I was just wondering if somebody had found a better solution.

My advice would be to think less about the number of "projects" they are working on and more about products...in other words, to encourage management for product value rather than for project execution.

Do people have a clear line of sight therefore to product value, and to the teamwork that must be demonstrated by them, and why? With that, they can be coached to self-manage (split, merge etc) so outcomes are optimized. As a Scrum Master you would not do such things for them, but you would shine a light on the opportunities.

Great thanks for your answers, dudes! Now I am developing such little departments in my firm too, I believe that I will try to organize their work more effective thanks to you

One of the best pieces of feedback I ever got was that a Scrum Master does not help the Scrum Team by solving a problem they could have solved themselves (obviously there is context here, but it helps me step back).

You talk about optimising the Scrum Teams - what have the Scrum Teams said? Do they see a problem? Is value being delivered in a transparent way?

I have no idea of the numbers involved here, but helping the team to limit their focus is a positive step forward. Your accountability is to help everyone understand the boundaries of Scrum, both within and external to the Scrum Team. Help make the picture clear (I've used McKinsey mapping to do this in the past, SCR) and then get the teams to own the solutions. At the end of the day, it's all about product value delivery.

In our company we have a team doing  a lot of little products & projects.

Each with their own PBL & PO or stakeholders. They work in little sub-teams on those products/projects, never all together.

If each one of these sub-teams have their own Product Backlog, Product Owner, and a Scrum Master (I'm assuming you are working with each team) wouldn't make them all Scrum Teams?  So what is the real problem? 

as they don’t work together on the same project. (To be clear, this team has 20+ small projects.)

How many of those small projects relate to a single product? For example if 5 of those projects add some kind of functionality to a single product, then you have the ability to craft a Sprint Goal and create 1 or more increments during your Sprint.  

To me the problem seems to be the one that @Ian Mitchell called out.  Scrum is centered around products but you seemed focused on projects.  Shift your attention to delivering products and product changes. Yes, many small projects can be used to do this but stop trying to manage projects and instead manage a product.