Good teams don't just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don't try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.
The quarterly and weekly cycles include time for team reflection, as do pair programming and continuous integration. But reflection should not be limited to "official" opportunities. Conversation with a spouse or friend, vacation, and non-software-related reading and activities all provide individual opportunities to think about how and why you are working the way you are. Shared meals and coffee breaks provide an informal setting for shared reflection.
Reflection isn't a purely intellectual exercise. You can gain insight by analyzing data, but you can also learn from your gut. The "negative" emotions like fear, anger, and anxiety have long provided cues that something bad was about to happen. It takes effort to listen to what your emotions tell you about your work, but feelings tempered by the intellect are a source of insight.
Reflection can be taken too far. Software development has a long tradition of people so busy thinking about software development they don't have time to develop software. Reflection comes after action. Learning is action reflected. To maximize feedback, reflection in XP teams is mixed with doing.