Agile is not a magic "change" vacuum

One statement about Agile that seems to haunt a number of projects is "Change is expected and welcome" during the project. This is true, but with conditions, and if expectations are not managed properly things can get out of control.

I've seen more than a few cases where customers think this means they can keep changing their mind with no impact to the project. When we explain that it is fine to change your mind, or ask for more changes, but something else has to go, they act as if we just performed some kind of bait-and-switch. The "problem" is especially prevalent because with short iterations we give the customer plenty of opportunities to review the finished features and make comments.

The essence of welcoming change has to do with making adjustments before the story card has been finished. If you are in an iteration and the developers are working on a story card, and in the process of discussing the requirements with the product owner (or bringing up an issue they have discovered) it is determined that things need to change, that is generally going to be ok as long as the spirit of the story does change dramatically and the estimate for the change is still in line with the original estimate. We want the finished product to be what the product owner really wants and needs.

But in terms of managing change once story cards are completed, it is important to explain the dynamics to your product owner/customer up front. The team will establish a velocity throughout the iterations, and for the purposes of planning, that velocity will guide what goes into the iterations. If you want to put something else into that iteration, then something else has to go. So if you are in the iteration showcase and the stakeholders make some comments about changing/adding something, then you need to decide number one whether it is worth it or not, but number two when it should be scheduled and what else is going to move as a result.

Retrospectives are great, but...

...they're not worth much if no action is taken afterwards. I haven't met many people who disagree that retrospectives provide a lot of value to the team. But without follow-up that value is often not realized, and if identified issues persist they can actually have a negative impact on the team.

In general, items that require follow-up need to be captured in a manner that will allow them to be followed up on. One method is to turn these items into new stories. I'm not always keen on this approach, since the items don't usually follow the spirit of the user story, which is to provide direct business value. Making the items technical stories often makes sense, as they can be factored into the iterations but don't meet the definition of providing business value.

A lot of the items that get brought up during retrospectives aren't related directly to development, which makes it hard to figure out where to put them. The issues list is a likely candidate. Another approach I've taken on some projects is to create a wall (like a story wall) which shows the retrospective action items and where they are in their lifecycle. Seeing a number of untouched items on the wall is a good indicator that the value is not being realized.

Another technique is to start future retrospectives with a recap of issues that came up in previous retrospectives, and where those issues stand. If the team sees that items are getting addressed, it could encourage them to participate in the retrospectives even more.

Lastly I just wanted to comment that the best situation is when you can get the team to decide on a resolution and take action right then at the retrospective. Not always possible (or advisable in some cases) but is a great example of realizing the value that retrospectives can bring.