ContinuousRetrospectives

I've usually used retrospection as I go to spot what I've done well and what I should do differently. If others will play, I invite them to increase the viewpoints.

One area I've really found this to pay is in local technical standards. I evaluate what actually works, whether it works for everybody or only some, and how many exceptions to espoused rules happen. I learned to downgrade "standards" to "guidelines" most of the time, and show by example. When reality disagrees with the "standard", bet on reality.

I also look for ways of making "correct" easy and "incorrect" hard rather than the other way around. If things are easier the right way, it's much easier for "correct" to become a habbit. I seek feedback on easy vs. hard paths from others, too.

What ContinuousRetrospectives do you use?

--BobLee 2003.04.02

As for rolling retrospectives, on my last job I learned a great way to organize quick team status meetings. For each project, we just capture the last week's worth of information:

Good - What good happened, including what did we get done.
Bad - What bad happened, including what we didn't get done. (and new problems, and new tasks.)
Info - What did we discover that is good to know.

Ended up in a simple 2-d matrix. Worked great, while allowing for our ignorance which was large. Actually gave us some measures about ignorance and our progress with it.

--JimBullock, 2003.04.03

I always ask people to tell me their obstacles in my one-on-ones. Then I review the obstacles over time to tell me if there's a trend. When I can, I share the trends with the group, especially if we've created the problems ourselves. JohannaRothman 2003.04.04

JR - If the team is mature enough, I prefer identifying obstacles in stand-up meetings instead of one-on-one. The odds are that someone will have or will think of a fix. Avoid exploring fixes at the meetings, though unless specifically to brainstorm solutions. One-on-one is a bottlenecked solution channel, while one to many may uncover better solutions. Of course, some "obstacles" need to be kept confidential, such as when the obstacle is a person in the meeting! --BobLee 2003.04.04

I've used team / status meetings and "one on one's" as complementary, focusing on different issues. Separation of concerns is a big tool for me, and this helps.

How are we doing (process) in one, how are you doing (process) in another.
How's the project progress (getting stuff done), how's your progress (growth and development).
Priority decisions, and commitments in one, coaching and investigation in the other.

With the two tracks, I also get to move topics from one venu to the other as appropriate. This takes some discipline because there are some failure modes.

Special pleading for team / project decisions in one on one's. Nope. I'll coach you in taking that idea forward, offer to facilitate if you want to take it forward in the team meeting or if I agree, take it forward myself. But the decision stays in the proper venu.
"Helping" others in team meetings easily devloves into calumny. Not acceptable either.

When I am being effective, I keep these distinctions intact. When the distinctions start failing, staff start coming to me saying: "We don't need one of these meetings." Sometimes I even notice that indicator when it happens. -- JimBullock, 2003.04.05

A new wiki about retrospectives for managers and facilitators has started here:

KeithRay 2003.09.25

A few of us attending AYE have also participated in the Retrospectives Faciliator's Conference. The term "interim retrospectives" for ongoing retrospectives was discussed extensively. They seem to be relevant for iterative development cycles, XP development, mini development cycles, etc. This is in contrast to the end of project retrospectives discussed by Norm Kerth in his book, Project Retrospectives. So I like these terms (continuous and rolling).

JohnSuzuki 2003.10.05

Updated: Monday, October 6, 2003