Scrum is probably the more difficult of the two to implement from scratch. Here's what I would suggest:
First Phase: Preparation
1) Spend some time grooming and prioritizing your backlog. The key here is to break the backlog items into small enough pieces. Most new Scrum teams fail early because they are unable to deliver software at the end of a sprint, and that is usually because their backlog items (user stories) are too large.
2) Have your team read up on the Scrum process, and go over with them the plan of implementation. Get their feedback, and feel for where you are getting pushback. Talk to them about TDD/BDD.
Second Phase: Sprint 1
3) Set up your first sprint. I usually suggest 3 weeks. If after 2 sprints, your team is having difficulty delivering working software, shorten your sprint length to 2 weeks. This will force you to break your backlog items into smaller pieces. Increasing sprint length is usually a black hole that you'll never get out of.
4) Implement all the required meetings, including the daily standup.
Third Phase: Automation
5) If you don't already have them, now is the time to set up your CI builds, and work on your developer's daily workflow. Encourage them to use the get latest > build > code > build > get latest > build > check in flow.
6) If your project doesn't already have extensive automated tests, now is the time to really start encouraging their creation. Your sprints will be more productive, and your working code will be more "working" if you can achieve good code coverage for your CI builds. Consider a check in policy that requires an increase in code coverage for a successful check in. This can be abandoned later on, once everyone is used to writing unit tests for their new code.
If you get this far and you haven't had a revolution on your hands, you can now start talking about setting up automated deployments, pushing TDD/BDD, implementing a code review policy, and formalizing an input/feedback process with your product owner that is more continuous. The last part can be quite difficult. Most teams end up with what we call Water-Scrum-Fall where the product owners act in more of a waterfall manner and only want to be involved at the beginning and ending points. The further into the organization you can push the agility, the more benefits you will see.
As for technologies I recommend TFS 2012. I've written a fairly decent overview of it's power on stackoverflow here. To recap, it combines pretty much everything you will need from both the PM side and the developer side under one umbrella.
On a final note: it is possible to do this in almost the exact reverse order, except for grooming your backlog (that should almost always come first). You could choose to concentrate on developing your team member's daily habits before implementing the structure of Scrum. Get them increasing your code coverage with automated tests, introduce a CI build, and (hopefully) set up automated deployments first, then create the sprint structure around that. Talk to your team, and see which they would prefer. Scrum is all about continuous value delivery achieved through automation and continuous communication. Get your team's input throughout, but if you get some pushback you may need to enforce some structure. Hopefully after a few sprints, they will see the benefits.
After some discussion with my colleagues, I believe I left out something important. I mentioned TDD/BDD, but I failed to emphasize the importance of integrating testing into your sprints. You need to include enough testing (unit, integration, acceptance) inside your sprints to ensure that your "working" software is actually working and fulfilling the product owner's needs. I've found that one of the most effective ways to achieve this is through multi-dimensional teams. Put a tester or two on your teams. Paired programming with a tester and a dev can be incredibly successful if they can work in a collaborative arrangement.