Retrospectives are simple, but not easy. The general idea is to get the team together, establish a context, gather relevant data, develop insights, and decide what actions to take. Esther Derby covers the retrospective structure well in a slide presentation on her blog.
As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.
At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?
It was 1983 and I was in science class when I first heard the term entropy.
I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.
I'm occasionally asked, "Doc, we're looking at product X, Y, and Z, but we just can't decide which is the best one for our project. What do you recommend?"
I've used VersionOne, Rally, Mingle, Pivotal Tracker, Kanbanery, ScrumWorks, and a couple of others including Excel spreadsheets.
Retrospectives are an important (and frequently poorly done) practice. They provide an opportunity for discussion, learning, and adaptation. Without retrospectives, a team is likely to fall into a soothing rhythm and fail to recognize early the need for change.
But retrospectives themselves can become common and numbing. The same moderator, the same three questions, in the same room, at the same time .... (yawn).
Here are a few tips on keeping your retrospectives fresh.