Beware of Blaming and Judgmental Facilitators

 

I’ve been thinking about project retrospectives. Too few project teams participate in end-of-the-project retrospectives, and to few managers arrange for them. My clients seem concerned by the price of an outside facilitator and the cost in time to the next project.

To address the facilitator cost, I’ve suggested that any facilitator not on the project team is acceptable. Oops. I wasn’t specific enough. Any facilitator who understand retrospectives *and* is able to not blame anyone on the project team is an acceptable facilitator.

The retrospective facilitator has to be non-judgmental, and willing to postpone finding solutions to problems until the retrospective data is gathered and absorbed by the retrospective participants. In fact, I like to see the retrospective participants define their own solutions. One of my clients was attempting to use the process staff as facilitators for their retrospectives, but one of the process people was too eager to blame some people (“Those developers wrote bad code”) and was too eager to decide on a course of action (“You should use month-long iterations”).

Blaming people, especially in a retrospective where the objective is to see the history of the project and learn from it — to see how things got the way they are — is counterproductive. And it’s not just counterproductive for the moment. Blaming will prevent people from fully participating in future retrospectives.

And, as much as I’m a fan of iterations, deciding that month-long iterations is the Right Size during a retrospective is premature. Maybe 3-week iterations is the right duration. Maybe 5 weeks. Maybe even 2 months, while using a staged delivery lifecycle. Until people look at the entirety of how they are willing to work, a retrospective is too early for someone *not on the project team* to decide how long the iterations should be.

So schedule retrospectives as you schedule the end game. And make sure you select a facilitator who understands enough of the issues to be helpful, but will not push the project team into one direction or another.

Leave a Reply