I'm not pushing you to use Scrum, nor I do think it's the best thing since sliced bread - not at all. But if you're willing to try it, the following recommendations may come handy. First, let me recommend you some excellent literature, then I'll present several myths I had to fight. And finally I'll show you a possible solution for projects that are not iterative (and thus not suitable for Scrum) ...

Literature

I've read a lot of articles and books about Scrum over the year, and I'll explicitly recommend just two books available at infoQ.com, preferably in this order:

1. Scrum and XP from the Trenches - A practical introduction to Scrum (description of basic principles, how Scrum was implemented in one company, along with a description of other options etc.).
2. Kanban and Scrum - making the most of both - Scrum compared to Kanban, which is basically an alternative methodology suitable for projects that are not iterative. A very nicely illustrates ideas behind those two solutions.

And I definitely recommend Scrum Checklists, i.e. checklists for various Scrum-related activities. Do you need to organize the first "sprint planning" and you're not sure what all needs to be done? Just find the proper checklist and you immediately know what to prepare, who to invite etc, A big help for the first several sprints ...

Tools

There are many tools declaring themselves as the best solution for managing Scrum projects. My recommendation is very simple - don't use them.

Not so obvious Scrum pitfall si that it's very flexible methodology, designed so that you can easily adapt it to your needs, so in the end everyone uses their own unique version of Scrum. The tools are usually designed to support every possible Scrum variant, which makes them absurdly complex. Don't do that, it really is not worth it.

To do Scrum, a sheet in Excel (or Google Docs) is more than sufficient - one sheet for backlog, one sheet for each sprint, and that's it. It's simple, it's elegant, it's effective.

It's possible your company rules demand some more details (e.g. how much time was burnt for actual development, how much time you've spent on meetings etc.) - but it's very unlikely the Scrum tools will allow such things.

And yet another disadvantage of the tools is that they often oppose the communication side of Scrum. Mybe you don't realize that, but the fact that you're standing every day at the scrumboard for 15 minutes, moving post-it notes, explaining what you've done yesterday and what you're going to do today, that's a pretty significant communication. By leaving the physical scrumboard, and moving it to a virtual world, you're going to loose it.

So even if you finally decide to use such tool, keep the daily scrums and physical scrumboard. I've seen dropping this (scrumboard and daily scrums) with distributed teams. There's nothing easier than choose a more appropriate time to do the daily scrums, and do it using Skype for example.

Myth about customer

The first myth I had to fight is that to use Scrum, the customer has to actively cooperate. That's not true. Sure, it's a big advantage when the customer cooperates, sets his "Product Owner" and performs regular testing after each iteration. But it''s not necessary - most of the projects we do are "fixed time, fixed price" projects, when the customers cooperate on the analysis but not in the development itself. Despite that, we're using Scrum to manage these projects.

Ask yourself a question - if you're not going to use Scrum, how will you manage the project? Because you have to manage it somehow, regardless of the customer non-cooperation. There's nothing that prevents you from managing the project using Scrum internally - doing sprints on your own, etc. And the customer actually does not need to know you're using Scrum.

It's definitely a better decision than throwing out Scrum for no reason ...

Myth about Product Owner

A similar myth refers to roles, namely to the fixed idea that Product Owner has to be someone from the customer. In some cases there really is no suitable person at the customer side - sometimes there is not a person with enough knowledge, sometimes the person is not the right candidate (e.g. a PM) as he fiercely fights against the team (which is a problem as Product Owner is a member of the Scrum team, not an enemy).

The point is Scrum does not prescribe that Product Owner has to be from customer - it just says the person has to be able to sort the backlog items according to "business value" and that he should be able to manage the backlog during sprint planning (split the items into smaller ones etc.). So if you need, you can choose a Product Owner from your company ... e.g. a skilled business analyst, or even the Scrum Master himself.

If you've just thinking "But Scrum Master must not be Product Owner!" you're a victim of another myth. Scrum prescribes roles, and it does not say a single person must not represent several roles at once. It's quite frequent that a Scrum Master is actually a regular team member involved in the actual development. So why a Scrum Master may not represent a Product Owner too (I'm not saying that is an optimal solution)?

Kanban

Sometimes the development reaches a point when it's not suitable for Scrum anymore. For example you've implemented all backlog items, and you're starting with FAT tests, there are some bug reports from the customer - that's not an iterative process.

In that case don't bend the Scrum too much - just choose an alternative methodology, e.g. Kanban. It shares a lot of Scrum ideas but it works very differently and is much more suitable for ad-hoc tasks.