At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As this is the 12th principle, lets kick off by reminding ourselves about the Agile manifesto that is behind all of the principles.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

This principle should be all about reviewing your activities in the context of the Agile manifesto and making adjustments to become more effective. (or more Agile if you like.)

Agile means trying to be flexible and only doing what is necessary in order to be successful. Therefore your Agile approach cannot be  “set-in-stone”. Nothing is mandatory in Agile but an organization (or project) may demanded certain processes to be followed. It is important to always review what has been done and what will be done in the next iteration. And essential to always question the logic behind everything. This will help a team gradually evolve and for improvements to emerge as a natural by-product.

Formal sprint retrospectives are one key approach used to review and learn from recent events. But even the format / timing of these should be questioned, regular short reviews are probably better than lengthy post-mortems. Depending on how mature your processes are and how rapid the sprint cycle is, maybe a bi-weekly retrospective is overkill. So you might opt for a monthly review. But whatever approach you take the key is about learning lessons and implementing changes.

In Waterfall environments, I have all too often seen lengthy post implementation reviews take weeks (or even months) to organise and weeks more to document. Whilst I have seen these reviews often document some great learnings I have (unfortunately) also seen little action / adjustment following the reviews. In an Agile world, if the team really buys into the manifesto then this needs to be something which will be guarded against. Short reviews with clear actions, making minor revisions to processes followed in every sprint should be the intended outcome.