How to know if Agile is right fit for project or not?

One of the common question I am asked is, How do I know if agile is right fit for my project or not?

While there could be multiple factors influencing this decision, here I am reviewing the top 6 points that shall help you make a decision -

1. Team's location - well, while many would debate on this, but it is not that easy to run agile projects if team is spread across multiple locations/sites and in some cases floors. If you are considering "scrum of scrums" scenario, you may have those scrum teams across multiple locations/sites but 'one scrum team" should ideally be co-located.
2. How urgent the changes are - If changes are urgent, frequent, only model that could save you is "agile", so don't look further,, go for it. It is in the core of agile to be able to support business agility.
3. How clear the requirements are - Sort of connects back to the point #2, if the requirements are not clear upfront (well low level), so this would mean that frequent changes, so agile is the model to go for. 
4. Can it be sliced into smaller usable chunks? - Agile demands the work to be broken down into smaller chunks, and each of that chunk should be "usable" some way. If that's not viable, agile might not really fit as you would end up with large chunks of work that would take several days to finish, making it difficult to adapt to frequent changes if need be, and further taking longer to demo or time to release to end user.
5. Access to PO/users - Agile needs access to Product Owner or user quite regularly (actually PO), and if no one person can take charge of it, agile just won't work. You need someone who can write requirement statements (aka user stories), help groom the stories that development team can understand and implement.
6. Process v/s project - repetitive or new endevour? - Of course, go back to the definition of project - is it really a project or a process, if later, head elsewhere, it is not a candidate for agile.

List doesn't end here, but hope this helps get broad idea to start with. Happy to hear your views.

Scrum Team v/s Development Team

Lets understand what are Scrum Team and Development Team in three easy steps -

1) Scrum Team consists of three roles - Product Owner, Scrum Master and Developers
2) Every team member (apart from Scrum Master, Product Owner) in Agile Scrum is called a Developer (regrdless of their skills - tester, analyst, architect, SME, etc etc)
3) Group of Developers is referred to as 'Development Team'

Timeboxing v/s Parkinson’s Law

Lets understand the connection between Timeboxing and Parkinson's law -

1) According to Parkinson’s Law - "work expands so as to fill the time available for its completion". What that really means is that a worker will drag the work to use up all the time given to him/her - even if he/she can finish that work ahead of time. So if a work is estimated to take 100 hrs and a worker has completed 50% of work in 25 hrs, he/she will still consume all 75 hrs to finish remaining 50% of the work.
2) Timeboxing suggests to fix 'time to completion' for the agreed upon Sprint goal and the Sprint will end at fixed time (hence term 'time boxed'), so the developoment team moves together to achieve the Sprint goal within given time period.