There are at least a few questions here.

Self-organization and communication are important part of agile approaches but if we talk about Scrum there are specific techniques which are usually used (like stand-ups, sprints etc). So I guess you aren't close to Scrum, although it is likely you use some of techniques employed by Scrum.

1. Sprints. Sprint in Scrum are implementation of time-boxing, so your main constraint isn't specific functionality or milestone, but time. Basically you say "we'll do as much as possible in 2 weeks." If you can't achieve any milestone in 2 weeks (or whatever sprint length you choose for that matter) you just look for goals you may achive in this time span.

   Another difference between Scrum sprint and typical waterfall approach is that sprint should produce working result i.e. code should be tested and deployed during the sprint. With waterfall we typically have big phases like development, testing, integration or deployment organized in a row so milestone usually says "feature A developed" or "feature B tested." With Scrum you rather use definitions like "feature X completed." Having said that I don't know whether waterfall approach I describe here is similar to your case since you haven't described it in details.

   What to do with dependencies between specific features/sprints? Well, exactly the same which is done in every other approach - if something must be done as prerequsite for something else you do the former in earlier sprint.

2. Team(s) organization. It is said Scrum team shouldn't have more than 9 people. See other question here on maximum Scrum size (http://askaboutprojects.com/questions/1155/maximum-scrum-team-size). If you think about 60+ people working on a project what you need is several Scrum teams. Each should group every specialization needed to complete specific features, i.e. programmer(s), designer(s), artist(s), animator(s) etc. In other words single Scrum team should be cross-functional. If you don't need specific role to build features end-to-end just don't add it to the team or find them a different task.

   Because you would have several independent teams you'd need to synchronize their work. There's a thing called Scrum of Scrums which is designed to deal with that. Single person from every Scrum team attends Scrum of Scrums where all interactions between teams happen. This is the place where you discuss all dependencies between teams and/or features, impact of implemented changes etc.

   Team sprints may be synchronized and that's a good idea since every day every team should be on the same page (most of the time). On the other hand if that would be too artificial you can allow to work every team with their own rythm.

This is how it should look like in theory. If that's something which would be too painful you may consider using a few techniques without fully embracing Scrum (which requires pretty much discipline by the way). Choosing evolution rather than revolution would make a transition smooth although definitely much longer. Additionally you may decide to change or adjust the course along the way deciding some of Scrum pracitces just don't work for your team. Time-boxing, although generally a good thing, doesn't work in every situation - sometimes your constraints are focused more on features (milestones) than on time spans.

Between the lines, I read one of your questions is "isn't it all just common sense?" and I think the answer to that is yes.

I think any methodology or paradigm is an attempt to codify common sense. The "code" is not hard and fast though. You can claim you are using Scrum and break its rules just as you can stretch Object Oriented design or code outside of a Model-view-controller paradigm. The question comes down to what are the repercussions? In the end, if you have good reasons for doing it and you properly document them, then breaking the rules is always beneficial. Why else would you break them?

You've got a team of 60 people working on milestones of a certain size, spaced at certain time intervals. If your product would benefit from more frequent releases and would not be harmed by some ambiguity surrounding what those releases contained (at least until closer to the release date) then you might benefit from using Scrum. For example, you'd be getting more timely feedback from your customers that way.

But, I don't see the benefit of changing your organization to follow any set of rules so that you can call yourself a Scrum shop - for one thing the interpretation of Scrum varies a lot. You will read a lot that claims not only that Scrum is the new sliced bread, but that it just doesn't make sense to slice your own bread ever. I argue that common sense dictates what you should do. In my organization we recognize a lot of the benefits of Scrum. We adopt it where it works and don't where it don't.

It would help if you could be more clear why you are considering moving to Scrum, what problems you are hoping to solve by this. For your sake and your organization's sake, DO NOT decide to adopt a different way of managing software development projects simply for the sake of being trendy. What kind of problems are you encountering with your current approach? Why do you think Scrum (or a more agile approach generally) may help you and your organization?

To understand more about moving from a "traditional", plan-based approach to a more agile method, consider doing some more reading. One book that you might find helpful is "The Software Project Manager's Bridge to Agility". It does a reasonably good job of mapping the PMBOK to agile management - if you're a PMP, then you would find it helpful. I recently posted a review of this book on my personal blog: "Building Real Software".

If you are serious about moving to Scrum, I would also recommend that you, and some of your colleagues, take the time to go through the Certified Scrum Master course so you understand the method better. And unless you are really in trouble with your current approach, I would strongly advise taking a careful, incremental approach to change: try a pilot approach, or, as Mike Cohn (who knows an awful lot about Scrum adoption) advises in "How do you get from here to Agile?", transition incrementally.

Scrum and agile can be described as a collection of "best pm practices." When you know PM well you've seen most of the things in agile/scrum. HOWEVER your questions indicate some substantial misconceptions.

Go get a couple of the key books and read them.

Ken Schwaber and Mike Cohn are the authors to start with. Henrich Knieberg also put a free booklet together on his "adopting scrum" experience called "Scrum from the trenches."

I'd also say invest in a training course.

If the model doesn't make sense to you, there is something fundamental missing in your knowledge.

this might help http://www.extremeprogramming.org/; it's not uncommon when making the transition to pick and choose the rules and associated practices that solve your immediate problems, then add the others as you become more comfortable with the new process/paradigm

everything you know is not wrong, it's just reorganized ;-)

You are not outdated. There's no best-before date on good management.

If you are effective, you are using the right approach.

If you are learning about other techniques that could improve the way you and your team perform, and are willing to adopt them, you are doing what a professional should do for their personal development and the betterment of the organization.

There are good answers on this post to the technical questions. As to the personal side of the question, sounds like you are doing all the right things.