Agile in support/maintenance team

It seems that you're focusing on two specific practices commonly found in agile methods - shared backlogs and daily meetings - and struggling to apply them to your context, rather than examining the underlying values and principles.

Broadly, agility appears to be valuable for support and maintenance teams. They are frequently unable to plan over a long period and often need to reprioritize their work. Specifically, the values of "responding to change over following a plan" and "customer collaboration over contract negotiation" seem like they would be valuable for such a team to embrace. Some of the principles, such as delivering frequently, working together, trusting the team, working at a sustainable pace, technical excellence, and self-organizing teams also seem relevant.

You don't provide a lot of detail about the context - how many products or systems these teams support, how big the team is, and how long their projects typically last today. There's also no motivation for why someone (who?) wants to look at agile methods. However, based on the limited description available, it may be possible that some frameworks are not suitable. Nevertheless, eliminating certain frameworks from consideration doesn't preclude the adoption of agile methods.

Scrum is best suited for teams working together on complex product discovery and development with a shared Product Goal. It isn't a ticket managing tool. In my experience it isn't ideal for what you're trying to accomplish. I see no value in a Daily Scrum without a Sprint Goal.

I have worked with teams to apply Kanban and be more effective in situations such as yours. Visualize the work, limit work-in-progress (WIP), measure flow (e.g., cycle time, work item aging), and continuously improve. Consider a shared Kanban system with labels or swim lanes by project.

Agile is a set of values and principles, not a methodology, and Scrum is only one way to take advantage of agility.

All the best!

My task is to propose a way of implementing Agile methodology in our support/maintenance team

Who actually wants this to happen, and why? What outcomes are they expecting from this change?

I'm finding it difficult to grasp how to implement Agile methodology in this team, where people rarely work on the same projects. Typically, only one or two people are assigned to a project at a time, and they don’t know what the others are working on.

Is there really a team then? It doesn't sound as if there is much need for teamwork, especially when people are being "assigned" by others.

I don't see any value in creating a shared backlog or daily meetings. Would appreciate any help in that regards.

If you don't, neither will anyone else. They still have their day jobs to do, the same old way, and that's what "good" currently looks like.

Systemic change cannot be delegated. Find out who is sponsoring this initiative for agile practice. Find out what their vision is and how they intend to communicate it more effectively, along with enough of a sense of urgency for any change to happen at all.