Many teams try Agile methods, or rather techniques. Some of them fail, and they suffer from this failure later on because it induces resistance in the rest of the organization and makes later attempts at Agile adoption much more difficult.
The following are five patterns of immature Agile implementations. What's common among them is that the team concentrates on some superficial technique without really embracing Agile values.
Usually the team starts with stand-up meetings, and these fail because it simply hurts their legs to stand for one to two hours daily! Moreover, the meetings are boring and take up a lot of time. The team members feel that this "Agile" thing is naive and wastes their time.
Teams do sprints -- one sprint for every Waterfall phase. That is, a sprint for analysis, another for design, another for development, and a final one for testing. So the process simply becomes Sprintfall rather than Waterfall.
Team do sprints -- one sprint for every big requirement or group of requirements. The problem with this approach is that no feedback loop exists. In other words, the team has split a big Waterfall project into smaller ones. That just causes bigger management overhead.
Teams use sticky notes and decorate the walls with whatever they do, even with requirements in a typical Waterfall project. After a while, they lose interest in updating the board notes, because every step takes a lot of time (one to two weeks), and they cannot see any value in maintaining two databases of requirements and tasks (board and electronic versions).
The team does everything just right but does not take feedback from customers. This is somewhat better, but it's still Waterfall in the main. Teams iterate to get feedback and to adjust their development efforts along the way. If they do not get feedback, the value of iterating is not realized.
These are some common failure patterns; there are many others. To tackle these failures, you may try to apply other techniques that would help elicit the value of these non-value-adding techniques.
Let me give some examples. The first failure pattern (long stand-up meetings) would work if we just applied another technique: maybe standing against the Scrum board, and limiting discussion to task status for the recommended short meetings. The second failure pattern (one sprint for every big requirement) would be resolved if we broke down user stories properly into smaller ones. The fifth failure pattern (sticky-note decoration) would work if we applied tracking inside the iteration on technical tasks that are no more than four hours long.
One more piece of advice: Do not be shy about saying out loud that a given technique isn't working!