[Sigia-l] Re: post mortem help

[Paul Hodgetts]

Wendy Cown wrote:

 > I've looked online for resources and have found some helpful fodder to get
 > people thinking about the project.  So I was hoping for personal experience
 > and tips for getting the best results, techniques for leading sessions,
 > and being something we can build upon.  At the moment it's getting client
 > feedback I'm researching online: to elicit their thoughts on how the
 > process worked well and what can be improved.

Another, perhaps more positive name for a postmortem, is
retrospective.  Postmortem always sounds to me like the project
died.  ;-)

One of, if not the definitive source on retrospectives is Norman
Kerth's book, "Project Retrospectives: A Handbook for Team Reviews."
He also maintains a web site at http://www.retrospectives.com/ .
The web site has some good materials and tips, but the book pretty
much covers everything you need to know about retrospectives.

The basic format for a retrospective is to provide the participants
with the opportunity to reflect on and discuss what happened and
what was learned from the project.  There are several common
formats for the topics and questions that are posed, but in general
they follow the format of identifying things to keep doing, things
to stop doing and things to do different.  Often the team also
identifies lessons learned and things still to figure out.

I've had the most success when I start with personal observations,
i.e., allowing individuals to reflect by themselves.  Then I move
to directed dialogs in small groups to allow the ideas to filter
out and be clarified and reinforced.  Then I use team dialogs to
collect the ideas and identify those that are important to the
team as a whole.  I find it key to choose and structure the
activities in a way that guides the team to reach meaningful
conclusions and ensures that things don't degenerate into a
meandering conversation or bitch session (although sometimes a
cathartic free-for-all is just what the team needs ;-).

Always have as an end goal to produce action items for the team
to agree on and take into the next project for improvement.  There
is nothing more frustrating to a team than for them to spill their
guts in a retrospective, and then have nothing come of it.

It's important to make the environment as safe as possible,
especially if you think there are negative things that will come
up.  Even when it's not expected, most of the time some negative,
often emotionally charged topic will come up, so be prepared to
handle it and any resulting conflict.  Watch to see if the
presence of management affects the team members' openness.  Watch
for dominant personalities, especially team leads, seniors, etc.

Make sure the participants include anyone that may have something
to contribute.  It's frustrating and de-motivating if a small set
of the team ends up charting the course for everyone.  Widen the
participants as much as feasible, including customers if possible.

IMHO (and I'm biased, see below) a retrospective should be led by
someone who was not part of the project, and preferably is from
outside the organization.  The retrospective facilitator should be
able to guide the retrospective without preconceived agendas, and
can handle the potential conflicts and emotions that can come up
when folks are invited to reflect on things and speak their mind.
It's hard for someone with a vested interest in the project to do
that effectively, especially if they are new to conducting
retrospectives.

That was just an overview.  I hope it helps.  If anything sparks
more questions, please feel free to ask away.

Small plug -- my company, Agile Logic, offers retrospective
workshop and facilitation services.  We use them all the time as
part of our iterative/agile process coaching (including using
them to evaluate the results of UI/IA efforts), although there is
nothing that ties retrospectives to agile processes per se.

Regards,
Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
Agile Logic  -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML