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.

Different Agilities

I've worked in many environments that have adopted a basic concept of "agility", & then gone on to define what they mean by that. In many cases, XP has been the dominant idea, because the methodology comes from the dev team, & XP is very much oriented towards software developers - those with the knowledge, skills, & intelligence - defining their own work practices. Management lets them play their little games & carries on regardless. I've also been exposed to Scrum-influenced environments. I use the term broadly. Someone better qualified than me refers to them as "Scrum-but" - as in, "we follow scrum, but we don't ..."

Once upon a time, I was in the camp that said XP is great for software development, Scrum can have a much broader audience, & agile can be applied in some way to any part of any business. Essentially, though, you have to pick a methodology & stick to it. The more I look at methodologies in isolation (or else in a mix), the more I have come to realise that they're not so incompatible.
I'm not suggesting that XP & Scrum are complementary, for example, but they are not mutually exclusive. There is nothing in one that negates the other. In fact, you might say that, with the same goals, the gaps in best practice that one has is generally an area of focus in the other.
For example, XP is very much around driving the development process from developers' practices - empowering them to ensure that they can contribute to the best of their extraordinary ability. Scrum is more about having a team infrastructure in place for the product development environment that ensures that the product is the best it can be through a whole-team effort. Different focus. Same results.
In the cases of both XP & Scrum, the agile principles are being followed to ensure that time isn't wasted on useless things, the people with the skills concentrate on what they're good at, & that the customer gets a product that they actually want. This is the crux of agility - & what waterfall models could never achieve.

I may be working in a pure Scrum environment, but we're adopting XP-inspired practices to make us stronger. You could say that we are still in XP-but, but we're going forward to become as agile as we can be, learning better ways, reviewing ourselves & our processes. We can only get better by looking at, & adopting, different agilities.

Stand for Something

One of the elements of agile development is that everything you do must have a story attached to it - some kind of narration that allows anyone to succinctly describe what it is that they're doing & why. This is very important. If you can't communicate the idea of a feature or a product, then the chances are that you don't understand what it is either. Many IT people don't see communication as a key skill. Such people struggle in an agile environment, where communication is everything.

But, it's not just the features that need a story - the team itself needs to know who it is, & what its purpose is. Again, there is some confusion here, because non-agile teams have roles, where everyone has their place, yet agile teams encourage a breaking down of this traditional view, so that everyone should be capable of, or involved in, most aspects of the product development - including non developers. This actually makes the lack of roles take on more importance - it is no longer the case that people know what they're doing because they have a role, they are a part of a team, where everyone has input to defining the roles.
A team of equals needs to define itself. It needs boundaries, it has expectations on its members, it must set expectations in its customers. All of these things need to be communicated accurately & appropriately - a medium & a message.

Agile methodologies are based on Principles, but also encompass Values & Practices. Although the agile principles are easily accessible, the values held by a team, a company, or an individual are varied, & need to be understood. Similarly, the practices need to be described so that they can be followed & referred to. These aspects are the story of the team - they describe who they are & what they do. The team members have to believe these things, support them, review them periodically, communicate them to project stakeholders (the contract), & live them. These aspects should be referred to when any question arises where there is no right answer. This is not a question of management stepping in & making a decision - the team needs to be empowered to enforce its own rules on itself.
The agile team needs to tell its own story & needs to stand for something.