Reduce Scrum ceremonies when most of the team members can only spend 50% of their time on the project

The reason behind this was that most of them could only allocate 50% of their time to the project because they had commitments for other projects. What should you do in such a case?

What the Scrum Master should do is make this situation (impediment) transparent to help the organization understand that partially allocated people impact their focus, and people cannot be productive when multi-tasking.  You may also want to ask the Development Team how they might self-organize into dedicated teams, and propose the solution to the organization.

Cutting back the time-boxes for the Scrum events isn't the answer.  Scrum works better with dedicated, cross functional team members.

The reason behind this was that most of them could only allocate 50% of their time to the project because they had commitments for other projects. What should you do in such a case?

Have you found out why, as Scrum professionals, they are agreeing to do this work at all given that they are unable to commit to implementing the framework?

What would the consequences be if they said “no” to this project on the grounds that professional standards would not be maintained?

First of all thx for the quick replies :-). Thing is the team members are not Scrum professionals and saying "no" to the project is not an option. I did address this already with the governance bodies as a risk (impediment) for the project but I'm not hopeful this will be mitigated soon. Would it make a difference if I change the Sprints to 4 week cycles instead of 2? 

Rene, just my opinion, but if you are serving a team that doesn't consider themselves working in Scrum, and work is being pushed to them instead of respecting their assessment of what they are capable of completing, sprint length is the least of your worries.

From the Scrum Guide:

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. 

Timothy, I fully agree with your statement but that's not the case for my project. What I meant by saying that they are "not Scrum professionals" is because at the start of the project the team members had 0 knowledge of Scrum and a scrum course I gave them at beginning of the project only gave them only a mental picture of the scrum roles, artifacts and rules. Doing it in real life is something different, my struggle is that the team wants to do scrum but because they cannot dedicate their time fully on the project, the number of scrum events in a 2 week sprint eats their capacity to deliver stuff.      

Doing it in real life is something different, my struggle is that the team wants to do scrum but because they cannot dedicate their time fully on the project, the number of scrum events in a 2 week sprint eats their capacity to deliver stuff.      

Rene, I wanted to write a longer comment and address several of the points you raised, but lack the time. So I'll cover just the above.

"Doing it in the real life" is the whole point, don't you think? The theory is there (on paper, and then in our minds) for us to be able to act in "eal life" (ok, ok, if we're in a Matrix, like many, including Elon Musk suggested, then I take it back :) )

Even if the team cannot be 100% dedicated, I'd argue there's a hell of a lot of work they can do regardless of the need to be in the events (which, let's be honest, are just a handful and don't last days!).

However, you/your team need to raise this limitation to management, point out the issues you are having and support the need for corrective measures. One of these measures could be, for example, to have smaller, dedicated teams that can support the product(s), hence securing the necessary focus and committment. The word "reorganisation" is definitely hated by many, but perhaps it's what you need. So aim for self-organized, cross-functional, team(s), and see where it leads you.

Coming late to this but I have an opinion that is different from the others and probably won't be real popular on a scrum.org forum but I've not shied away from it yet.

...my struggle is that the team wants to do scrum but because they cannot dedicate their time fully on the project...

Since the team wants to do Scrum but is not allowed to by your organization you are most likely going to fail at doing it "by the book".  You are living what I call an Agile Revolution because you are starting at the bottom in small pocket of rebels trying to force the rest of the organization to allow you to make your own rules.  In my experience that never works. However, I have seen this situation succeed in adopting some of the practices of Scrum and other agile practices that benefits the team. And in most of those cases, other teams notice and want to adopt some of them also.  But it has never resulted in Scrum because as the guide says 

 Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

As a Scrum Professional, you may have to become of an Agile Coach and coach the team on how they can adopt agile principles that will help them be more productive and efficient.  Take the benefit of the Scrum Events and adapt it to a time frame that provides that benefit but fits into your organization's demands. Try Kanban practices of "boarding" your workflow, monitor for bottlenecks and address with Work In Process limits. Use the Daily Scrum or Daily Standup (origins Extreme Programming) as a means for conveying progress or lack of.  Listen to the team to find out their frustrations or impediments and then help them introduce some type of agile practice to help alleviate the pain.

Ken Schwaber has compared Scrum to a mother-in-law. They're both going to point out all your faults, but it's up to you to solve them.

It's absolutely fine to take bits of Scrum, but as was pointed out earlier, the result is not Scrum.

When it becomes unpleasant to follow the rules of Scrum, it's good to understand the real reasons why.

In your case, Scrum might be helping you and your colleagues to understand the negative effects of splitting focus between various priorities.

It could also be that the team are finding the events frustrating or a waste of time. This might be for the reason you have already mentioned, but there could be other causes.

For example, if the Daily Scrum isn't valued, perhaps the developers see it as a status update, or maybe they don't collaborate as a team towards a shared goal.

For the Sprint Review, it could be that there's no meaningful stakeholder feedback taking place, or it's being done at other times instead, without all of the right people in the room.

For the Sprint Retrospective, it might be that no meaningful change occurs as a result of the discussions.