You have said that you want to adopt Agile because it decreases the time-to-market and increases the productivity of your developers, so I'd like to focus on those particular aspects.
Time to market
In traditional Waterfall products, stakeholders only get one chance to sign up for requirements. In Agile, you can produce a much smaller vision and then add additional requirements afterwards. That's your best way to get to market quickly. To do this, you'll need to ensure that
- your codebase remains easy to change
- you can deploy your code easily, repeatably and reliably
- your stakeholders are prepared to engage and talk about what they truly need, instead of what they want.
So you'll need to do a bit of educating your stakeholders. Read around subjects like Story Mapping and Feature Injection, and talk to them about what they'd like to get from Agile. Bear in mind that the certainty they used to get with Waterfall's analysis won't be there (if it ever was!), but they'll get more chance to change their mind and shape the direction of the product, instead.
For the practices which will help you keep your codebase easy to change, I suggest Kent Beck's "XP Explained". Also look extensively at TDD, BDD and Continuous Integration and Deployment.
Having showcases to your stakeholders within an environment that's as close to production as possible really helps. I recommend doing this every two weeks. If you find it's very easy to deploy and your stakeholders want more engagement, you can shorten iterations to one week. If you find it's very hard to deploy, make sure that you can get feedback in some form every two weeks - even if it has to be on a developer machine - then release every month or two if you can. While you're doing this, work out what's making deployment so hard and start automating that. If there are political bodies stopping you from deploying regularly, work out what you might be able to show them to shortcut their gatekeeping processes, and see if you can move them into a role where they educate the team and continually check instead of having one big check at the end.
Agile isn't really a way of getting developers to do more work in less time. Instead, developers have less rework, less wasted effort in terms of work done "just in case", and a more collaborative approach that lets them learn from each other and from the rest of the team.
Having the team co-located is the single biggest factor in enabling this to happen, IMO. Developers have to be able to collaborate with testers to find bugs early, while they still remember how to fix them; with analysts so that they can question any part of the requirements they don't understand; and with each other so that they can share new ideas, designs, and things they learn. Most of the XP practices, especially pair-programming, collaborative code ownership, and TDD, will reduce bugs and therefore rework too.
A warning about Scrum
This applies particularly if you're using estimation and velocity measurements.
A lot of what you're about to do will be new to you, and it'll be hard to work out to start with just how long things are going to take. If you start using estimates and velocity measurements to track the work, the estimates might be quite a way out to start with. This is normal.
Scrum also doesn't mandate any technical practices which will help keep code easy to change. For the things you're after - time to market and productivity - those technical practices will be essential. For that reason, please don't just put Scrum in place - also start adopting excellence within your development work, and flex your process around that. You'll get a lot of benefits just from having higher quality, collaborative code and a high-learning environment.
Coaching and training
It's highly likely that you'll run into problems. I've only met one company who self-coached from a couple of CSM classes, and they had an amazing culture. Don't be afraid to ask for help, and read extensively. Scrum isn't the only methodology out there and you may get ideas from other sources too.