The most common mistakes with Agile are:
Using it to try to 'push' development faster in the short term.
Thinking of Agile as 'quicker' rather than 'more nimble' and 'better'.
Focusing too much on the technique(s) and not the reason for doing them.
Not getting key long-term estimation benefits by failing to look at velocity.
Not using good tools that support the processes such as Pivotal Tracker, Trello or Trac, etc.
The most common mistakes with Scrum are:
Not being consistent with the approach of same time, say day, same place.
A lack of longer meetings to complement Scrum and provide analysis for bigger picture reviews.
Forcing developers who are less comfortable in a group setting to be in one.
Suggesting quick solutions that lack analysis.
Senior developers dominating discussions, intimidating junior members.
Also I present:
The Durrant Test.
Similar to Joel but for all jobs!
To the company in question:
Summary:
1. Are you well organized?
2. Do you have good production processes?
3. Are you actively making progress in my area?
4. Do you track defects?
5. Do you fix issues before making new ones?
6. Do you update a shared calendar?
7. Do you document needs?
8. Do you value focus?
9. Do you value good tools?
10. Do you test your ideas and practices?
11. Do new candidates do actual job tasks?
12. Do you share information freely internally?
13. Do you have retrospectives?
14. Are your scrums short and on-time?
Details:
1. Are you organized?
Do you have one system for stories and features (Microsoft Project), another for tracking bugs (Trello), another for tracking releases (a good doc spreadsheet) ? All these systems might be good, but the multiplicity of them is not good and it would be better for everyone to use one system, e.g. Trello or Pivotal Tracker (which is my favorite). Other items: Is an online shared calendar used by everyone? Are file shares and directories set up with good names and do they avoid duplicity of data? Does everyone know where to find the wireframes, the requirements and other important documents.
2. Do you have good production processes?
Are your production processes well documented? Have the documents been compiled by multiple parties and also reviewed by others? Are roles and responsibilities clearly spelled out? Do you have documented procedures for emergency situations?
3. Are you making demonstrable progress in my area?
For the area that you'll be working in, the progress being made currently? How fast is that progress and are there any major issues? What evidence of the of progress can be shown in the project tracking system, recent releases, dates of recent changes, etc.
4. Do you track defects?
Do you encourage everyone to enter defects in a commonly used system. Does the company base performance metrics on the number of bugs entered / resolved? This can be very counter-productive.
5. Do you fix issues before making new ones?
How large is the current list of bugs? How long have items been there? Is the list growing or shrinking and at what rate?
6. Do you update a shared calendar?
As with other tools this makes co-ordination easier.
7. Do you document needs?
Even in an Agile environment you can still benefit from documenting requirements.
8. Do you value focus?
Do developers have the ability to work in quiet and isolation in order to be able to be productive?
9. Do you value good tools?
What tools has the company spent $ on. What machines? What screens?
10. Do you test your ideas and practices?
Does the company do prototypes and get input from industry experts?
11. Do new candidates do actual job tasks?
Are candidates asked to do tasks during interviews that they would actually be doing in the course of their everyday job?
12. Do you share information freely internally?
Is it an open culture?
13. Do you have retrospectives?
This is an incredibly important part of Agile, taking time to review what you've recently done and what worked well and what didn't.
14. Are your scrums short and on-time?
It helps to be rigorous and start on-time, not 5 or 10 or 15 minutes late. It's also important to be done in no more than 5 or 10 minutes. Any detail or extended discussion should be taken 'off-line' and done after scrum is over.