"How should I change Scrum to fit into my organization?"
"With which part of Scrum should I start?"
"There is no Product Owner in our team, we don't need one."
"We don't do Sprint Planning because we planned all project phases at the beginning and execute that plan in 3 week sprints."
This is the wrong way! If you pick a few single methods or practices of Scrum the result will not be Scrum.
Or as Jeff Sutherland said: "You may change anything in Scrum but don't call it Scrum!"
One may argue this is just another dogmatic restriction of Scrum. Let's find out why it makes sense to leave Scrum as is.
Think generally about your team's definition of done. Everyone of your team is able to understand what you mean by saying "this story is done." It is just useful to have such a common basis of understanding. Now replace "done" with "scrum" and extrapolate your team to the rest of the world. The definition of Scrum is based on its roles, activities, and artifacts as described in the Scrum Guide or any other serious book on Scrum. Everyone in the world with such knowledge of the Scrum framework will understand what you mean by saying "we're doing Scrum." Take a look:
"done" = done
"Scrum" = Scrum
"not done" = not done
"not Scrum" = not Scrum
"I'm almost finished with this task" simply means "not done".
"We're using only a few things of Scrum" simply means "not Scrum".
It's that easy.
There is no binary black-white scale, of course. In the beginning of your transition to Scrum you will see many things that won't work as scrummy as intended. The important point is not to exclude these things right from the start of your transition. Always start with the full Scrum set even if nothing is working well. Go on, learn, inspect and adapt - with good mentoring and coaching your team will improve soon enough even if you think that is not soon enough.