Look Back in Wonder

One of the most important & misunderstood aspects of agile methodologies is review. This has been described in the agile principles fully, & Scrum, in particular, expects that the team review each sprint's achievements (relative to its goals).
Strangely, you would think that people would embrace this part of the process like any other, & yet it seems to be the first one to be threatened from the outside or the inside. From the outside, people in management who don't understand or support agile processes (or product development, I fear) tend to think of all meetings that developers have as being unproductive, by definition, because developers should be chained to their desks, coding. From the inside, developers who don't understand product development tend to think of all meetings that they attend as being unproductive, because developers should be allowed to get on with the  coding.
With everyone in agreement, reviews are the first meeting to get dropped from the process.

The big losers are product owners/managers & team/project managers. In both cases, reviews (& meetings in general) are their chief way of communicating - both expressing their views & getting feedback from the development team. Stand up meetings are not enough, because these should be short & to the point. Planning meetings look to the future. So, when do we learn from the past? How do we improve? How do we predict the future (estimate)?
Without review processes in place, the team will stagnate, & the product (& dev team) will lose out.

Once upon a time, CMM (the CMU Maturity Model) was used as a measure of a team's effectiveness. Most of the level differences were onion-skins of auditability - the habit of reviewing the coding, the product produced & delivered, the processes in place, the methodology. Although this kind of "heaviness" of measurement is usually associated with waterfall methodologies, it should never be forgotten that the thing being measured is the maturity of the company/team - their ability to have learned from their experience & apply those learnings to the rest of their lifecycle.

Any form of review should be looked at in terms of what it accomplishes. If it accomplishes nothing, then you are definitely wasting your time. This doesn't mean that you should stop reviewing, but that you should do something different to start reviewing things in a useful way - a way that gives meaning to the team & adds to its maturity. You only get out what you put in. Review your review process to invest it with effectiveness.

Without review, we wander through the product lifecycle with our eyes closed, groping in the self-imposed darkness, hoping that we're heading in the right direction, but incapable of planning the next step or understanding where we've come from. It's time to open the eyes - & all of the senses that we have available to us. It's time to look into the future by understanding the past.
It's time to look back in wonder.