Multiple Scrums and maintaining collaboration

I think you are mixing things . Three different "Projects" from one product backlog. How could one mould produce three different shapes ?
Sorry if i did not understand your point.

Sorry, perhaps I should reword it this way : 3 different modules (independently build and tested, integrated) to become one big product.

Hi Ikhwan,

I don't have experience with that but I can imagine that it would help to have one person as Product Owner for the whole Product (not just the modules). The 3 "Module Owners" have to report to this "Product Owner" (literal sense) and the "Product Owner" can decide controverse issues regarding to the whole product and not just the modules.

Hi Ikhwan, my assumption in replying your questions is "there 3 scrum teams that work on same product development and pick up the tasks from the same backlog"

Question:
1. Is this the right way of handling it? Or is there a better cohesive way to ensure there is 'fairness' (the amount of tasks is taken by each scrum team is equal)

"Each team takes same exact amount of tasks" as measurement of fairness sounds like misleading expectation that is taken as base to measure fairness. Each team has its velocity, and one team might be less experienced which could lead to its velocity to be lower than other more experienced team. Hence, load sharing the tasks equally between teams can set the team with a lower velocity to a failure.

2. I sense that this will contribute of a 'rivalry' between scrum teams. There is a chance of disagreements of the amount of fairness between teams. How do we ensure that these folks look at the product as a whole, rather than "I have done my bit, I shall not do other things anymore"?
3. How do you promote collaboration/teaming between scrum teams?

For last 2 questions I would suggest to use transparency as the mail rule.

As a Scrum Master I would try to understand why one team falls behind, is it a 1 time occurrence or is it the team trend? I would analyse the teams velocity in each sprint, see if the lower performing team needs some help to improve its velocity. Coach/mentor the 'falling behind' team on improving their performance. Next step is to be transparent on the issue(s) with all teams. Perhaps, ask the teams to find ways to help each other in terms of experience sharing/training. Typically, behavior like "I have done my bit, I shall not do other things anymore" comes when a person feels like the person works more than other team members. Also, as a Scrum Master I would re visit the project's goal, the role of each team in bringing the product to the customer, emphasizing that although each team has its own tasks, the tasks are coming from same product log, and technically the division by teams is just logical, as all teams are working on same exact product. Remind each team that different teams might have different velocity which is normal. However, again, each team should see that there are some actions taken to improve the "falling behind" team 's performance which eventually should illuminate the "unfairness" in how much each team accomplishes within a Sprint.

Thanks for the response.

I like the idea of velocity and the difference velocity each can take up. However, the velocity should be revisited every now and then to see the accuracy of it correct?

I currently do not have data on velocity - so how do I start?

Also, the last sentence on actions to improve the falling behind - is something that needs to be discussed in retrospective, where all the team attends? If you were me, how would you do it?

Some interesting ideas - I shall think more to see how I can adopt this. Thanks!

"I currently do not have data on velocity - so how do I start? "

Ikhwan, you mentioned this in your original question:
"We are able to finish it as per Definition of Done and everything works fine - team is self-organized, and very productive"

It seems like there is already some data in place which you can use to see each team potential.
So, I would suggest to see how many stories/story points were finished by each team in each Sprint. I believe by just analyzing this data you can see tendencies if any, weaknesses if any, strong sides of each team/even team members.

In any case, so far, it looks like there is yet nothing to address, and you are just trying to be proactive. Is my understanding correct? If so, you might want to keep your observations to yourself, and just monitor the situation. Issues should be seen and brought up by the team(s) members. Perhaps, that fact that one team is falling behind will not present any issues to other teams.

However if you see that some team member is not happy/demotivated, and it affects the team performance, you might want to understand why the developer is not happy, and coach the person on how he/she can change the situation, or perhaps take some other actions to fix the problem.
Hope this helps.