I have seen a lot of companies buy into the Agile/Scrum process and basically use it for every project, regardless of what it is. When is Scrum not appropriate and can cause more harm than good (generally speaking)?
If there are too many members. The particular number depends on how well the team all gets along.
It becomes difficult for everyone to feel like a team and be helpful to each other without taking so long learning what everyone is doing (generally).
I'd hazard a rough guess that 15-20 is time to start breaking up the team if possible.
When you don't have an appropriately-sized, committed team.
Scrum works well with 5 to 10 people who can be completely committed to achieving the sprint goals. It doesn't work well with huge groups or with people who have significant responsibilities elsewhere. There are ways to break up larger teams and still practice scrum. For example, a "scrum of scrums." But this is trickier than implementing scrum with a small team.
Both management and team buy-ins are requirements for scrum.
Scrum also doesn't work well if you are unable to define your goals, or break them down into small, quantifiable chunks.
Scrum will not work well if you cannot project your goals a couple of weeks into the future. If you have the sort of job where what you need to do changes dramatically when the phone rings (for example, support), then Scrum might not be the right process for you. It will also be a problem if requirements are imposed on you externally. Management must buy into the idea that they cannot change your backlog during the sprint.
If you have a project that has aspects that are more production related, scrum doesn't work well. Production tends to be more time-boxed oriented.
For example, in game development, the programming work to produce the software used to create the game can easily use scrum. However, the people who use that software to actually create the game (i.e. artists, writers, etc) tend not to work well with scrum.
FYI, we use scrum with different levels of effectiveness on large teams by breaking the team up into sub-groups. However, communication between the groups can be difficult if you aren't careful.
I am a fervent Scrum practitioner. However, there is one instance when we are not using this methodology.
If your project enters the deployment phase, where the only thing you are doing is fixing defects, for your Alpha and Beta phase, then using Scrum would be counterproductive. It is hard to estimate beforehand the complexity of a given fix and you have defects arriving all the time if your Alpha and Beta testers are doing their job properly. In that case, we have a scoring mechanism and we use cutoff values to know when to stop.
Without co-operatice customer you could not run Scrum effectively.
As as Certified Scrum Master, someone who practiced Scrum and thinks Scrum is better than sliced bread:
I would not use Scrum when I have a fixed deadline with a fixed feature set. With such limitations I would use traditional project managment, add fine granular work packages an do rigor estimations for those with developers. Then add developers to the project until you can achieve the deadline.
For Scrum you also need commitment from top management. Scrum will change your organisation (product managment, releases, QA) and without 100% commitment from top managment you will not - as a ScrumMaster - be able to remove impediments and therfor fail for the team.
Agile/Scrum, IMHO, is just another bureaucratic methodology that companies use when they have poor managment and don't understand what it is they actually do. Invented by people who like Starbucks® and charts.