Development team does not care too much about story points and other agile practices

Should I just enforce my belief on the teams?

Absolutely not.  As a servant-leader you do not enforce anything.  Scrum Masters are not the Scrum Police.

The problem in my team is that team does not take scrum/agile values very seriously,

As a Scrum Master it is your job to help them.  I would suggest that you do not try to do everything at once.  Start with one thing and work from there.  You have to lead by example and by incrementally improving based on the inspect/adapt method shows them the benefit. Find at least 1 of the values that they take seriously and use that to build upon. Ask them to try 1 thing and remind them that what they are only agreeing to try it for the duration of a single sprint. At that point it will be discussed, evaluated (inspection) and changes can be made (adaption). 

I am also going to pull out a card that isn't exactly covered in the Scrum Guide but is a basic principle of any Agile Transformation.  Is there someone in the organization in a position of authority that is promoting the use of Scrum/Agile?  If so, it might be beneficial if you were transparent with the information you shared here. Then you should help that individual to inspect and adapt expectations and behaviors at the team levels. 

Should I speak to development manager and convey my feeling and ask for support?

Is it possible that the team don’t think they’re accountable for managing their development effort because of the way organizational roles and responsibilities are constructed?

Thanks Daniel for the suggestion, I could definitely try one step at a time. And yes, in this scrum is being enforced by the company. You are right that I should make my manager aware of the situation.

@Ian Mitchell, team is in general very responsible. But I have the impression that team thinks the planning poker, standups all are just a waste of time.

Some new information popped up, apparently my team gave a feedback to the manager that i'm micromanaging and trying to be the boss.

I know in my head, i'm definitely not trying to do that.

But as they don't care much about Scrum and other values, I'm the only one telling them stuff about scrum and advising them/asking questions.

My concern is that if I don't ask questions/if I don't suggest improvements, i'm basically doing nothing. How do we improve if I stop asking people and team does not care about the process part?

Any suggestions please what can I do in this case? I'm getting the impression that it is a thankless job.

Remember that Scrum is a framework. It describes practices that provide benefit based on Empiricism and the Scrum values of commitment, courage, focus, openness and respect.  It might be better to start helping them understand and appreciate those before you can get them to fully understand and appreciate Scrum. 

Be mindful of the tone and vocabulary you use when suggesting things.  I typically start with something like "Based on textbook Scrum ...", "Scrum theory would suggest ..." or "Empirical evidence suggests ... " .  I also end with "but ultimately this is your decision on how you want to do it".  Let them know that this isn't something you are making up and that they are ultimately responsible for the decision.  Also NEVER SAY "This is how you should do ....".  We don't tell people how, we observe and suggest.  You can explain what you have observed, suggest something that you feel would benefit them and explain why you feel it would be beneficial. 

I'm getting the impression that it is a thankless job.

In a lot of ways it is a thankless job.  Your job satisfaction comes from seeing the teams become self-organizing and self-sufficient. A good Scrum Master is very seldom noticed.  This job is not for everyone. I know a number of people that have attempted it and walked away for various reasons.  You have to be able to find your own job satisfaction. 

Some new information popped up, apparently my team gave a feedback to the manager that i'm micromanaging and trying to be the boss.

Why does the team have a manager at all?

Nitesh Bansal, Under similar circumstances what worked BEST For me is the RETROSPECTIVE ! When done correctly you can put the ball in their court  :)

There are several nice ways to make it fun and engaging for collocated teams. Now, in your case the team is remote. That is a BIG drawback  as some of these methods like spider web or sailboat and speed car are not as fun anymore but can still be implemented. If you learn you will understand that basically they all work on the principles of allowing the team identify the problems in innovative ways using the anchors (process impediments) stopping the sailboat from moving forward (team progress); marking the value of each concern (each spider web leg) to identify the scope of the impediments that need to be corrected so we can focus on the longest (most impeding) ef first. 

Below is my Special method that worked for my for  two teams so far (currently testing on another mixed team, local + remote !)

Buy a Problem. (This is basically a modified version of Buy a Feature game which is a good technique for a PO collecting Stakeholder priorities)

Once you understand how Buy a feature game is played, the difference here is that instead of buying a feature, the users will bet on buying a solution for the process problem :) I don't know if it's my team composition or my style but it worked pretty well for us. Each team member gets to spend only 100 (or whatever amount you choose, it does not really matter as the key is the cap). Unlike features the problems are not valued (estimated). The value is whatever you are willing to pay ! Like I said it's a bid now. You can place all your bets on just one problem that you think is most troubling according to you. If none of the problems are your concern you can add yours to the list (we used a simple excel file). using these values we can generate a radar graph that looks just like a spider web (dynamic!). All you need is to find the one that the team bet most on and come up with an action plan. 

Now you may wonder, how this helps induce Scrum to teams?

Here is one real life example. The team placed bets against various factors like testing, defects, requirements, being remote (communication and other), code quality, documentation, management, time availability, predicting milestones for management, etc and eventually the clarity of requirements evolved as the most betted problem that needs solution. It's the team that seeking solution now. So I asked them for their suggestions after helping them agree on a schedule of dedicated events to clarify, prioritize and add enough details to the requirements, while carefully introducing them to Acceptance Criteria (I held back DoD at this time, half step at a time !!) and then I told them let us call this Backlog Refinement. Now they are doing one of the Scrum practices without knowing !

I advise you to check other nice methods to make retrospectives fun here. There are several other tools softwares and videos which I  would advice you to follow. Retrospective is your best avenue to make them do the work for you, but you need to be carefull, delicate and nudge them to talk instead of you dictating. Good luck !

For example story boarding (and therefore velocity) which you are asking the team to consider is only one of the several ways to measure the scope and therefore predict the timeline of deliverables with a team of consistent capacity. There are other ways. Instead of introducing them to story point estimation, ask them what can we do to figure out how much we can do it next sprint? How can we gather that insight? Explain how velocity will help us achieve that and that it needs story points as input. 

Thank you Daniel for your tips, i'll keep in mind your advise. It will help me deliver a message, but in a less conflicting manner. In the meantime, I communicated everything with Development manager and he has promised to provide some support and will talk to the team to push the Scrum methodology. I hope that will help a lot

Scrum is all about transparency, you SHOULD tell them you are there to teach them about Scrum, not enforce. If they "don't care" is because they can't see how valuable scrum is.

As a SM, you should work as a mentor/coach for the team. So, its a good practice to do a one-on-one meeting of 30 min with each member of the team per week. Use these meetings to understand each one, build trust, identify areas of self-improvement, ask for feedback on your job as SM. This will improve your understanding of the team (as individuals and as a whole ), enables you to draw a plan to "make" them "see" the values of scrum, improve communication quality and so on...

*Sorry for any english mistakes. Not my native language.

How did it go? What have you finally done? Did it worked?

Cheers.