I can only give my advice from my own personal experience.
One employer I had totally failed at Agile. Work was done on an ad-hoc basis, testing was non-existent, and requirements were documented in emails and meeting minutes. The only development method used was anarchy, or 'fire-and-forget coding'. Implementing some kind of software engineering method would have been impossible as developers were too overworked to set up some kind of story-tracking project management software.
At another employer, our team had a heroic member who desperately tried to establish some Agile best practices - we had a Kanban board, issue tracking, we used TDD and BDD (while not Agile in themselves, they tend to be present in Agile groups). Unfortunately, we lacked things like story points, estimation sessions, capacity planning, burn-down charts, velocity graphs - the kind of useful Agile project-management stuff that allows work to flow through smoothly. As a classic symptom of Agile going wrong, when our Kanban board got too full, we bought a bigger board :/
The place I'm currently in uses story points as a way of planning capacity with two-week iterations, TDD, daily standups, iteration-by-iteration timeboxed retrospectives and pair programming on most things. This is as a result of total management buy-in and client education.
It think that in order for Agile to succeed at a company, you need the following things:
- Project managers who understand Agile and who will use the tools appropriately.
- Developers who understand Agile, who are open and honest, with the discipline Agile requires
- Buy-in from the client. They need to recognise the benefits of Agile and be willing to listen to advice from their developers with regards to what can be developed in a given time-frame.
EDIT: It's also vital to make sure you have a good understanding of -why- things like daily stand-ups and short iterations are useful.