Rhythm is an important part of an agile team. Release planning, sprint planning, and daily planning all happen on a regular basis and allow a team to find the sweet-spot of operation: a comfortable and effective way of working together. Running a sprint for three weeks one time, two weeks the next and four after that feels clumsy and prevents a team from finding that natural rhythm, their runners high. If rhythm is so sacred though, then how does the retrospective fit in the agile picture? Why allow an opportunity to change things after every sprint and release if a main goal is to keep the team heartbeat steady?
The answer is because it works. Like with many agile techniques, this seemingly contrary approach not only works, but works well. In fact, I believe the retrospective is one of the most important parts of the agile cycle. The retrospective is the tune-up opportunity in the agile world, the method of discovering the peak operating efficiency. Because the discussion is conducted by the team itself, the likelihood of making changes that screw up the rhythm is low—a synergistic group isn't going to mess up what is already working. If it does manage to change something for the worse, during the next session the error should be recognized and corrected. I guess you could say that an agile team is like a washing machine; if it gets overloaded the results are spotty and if it gets out of rhythm then the banging will alert folks that something is wrong. The retrospective meetings are where a team figures out why things got out of balance or crammed in, and fixes the system so the all-important rhythm remains steady.