| DHQ: In Project Retrospectives,
you discuss the need for ritual in software organizations. What are retrospectives
and how can retrospectives fill that need for ritual? A
retrospective is simply a gathering at the end of a project. Everyone who was
involved with the project collectively learns what he or she can from the experience,
with the goal of continually learning to improve as a team and as individuals.
Sounds easy, doesn't it? But if it's so easy, why don't retrospectives happen
after every software project? I think there are several reasons, but one
is that holding a retrospective to review the project is not a habit. To make
it a habit, I introduce it as necessary ritual, as necessary as the ritual of
officially funding a project. Our industry, through its practice, has established
some common expectations for software: It will be late, it will be buggy, it won't
be maintained, it can't be extended, and it may not ever be completed. Companies
not willing to accept these conditions as givens need to learn how to get better.
There is no better time to learn than when a project has just ended, and there
are no more relevant topics to study than those coupled to a freshly completed
project of which the retrospective participants have intimate knowledge. I have
seen amazing improvement made very quickly by groups labeled "the worst in
the company." DHQ: Who should attend
a project retrospective, and how can people feel free to speak, without fear of
getting blamed for something? A retrospective is a collective
telling of the story of the software project. No one person knows everything that
went on in a project, thus everyone associated with the project needs to be invited—developers,
both senior and junior; testers; analysts; and yes, even the manager. Some
people worry that, if the manager is present, conversations won't be honest, or
the manager might use the information in the next round of performance reviews.
These fears undoubtedly have some validity, but in my twenty years of facilitating
retrospectives, I have never seen a case in which a manager's presence actually
created problems of this nature. There are some managers who don't belong at a
retrospective, but they know it and somehow find reasons not to permit the retrospective
even to be held. The problem takes care of itself. Nevertheless, even though
a manager's presence is unlikely to be a problem, the participants' fear of honest
discussion is real. To create an atmosphere in which safety and trust exist, I
developed what I call Kerth's Prime Directive, intended to serve as the foundation
upon which this ritual is built Regardless of what we discover,
we must understand and truly believe that everyone did the best job he or she
could, given what was known at the time, his or her skills and abilities, the
resources available, and the situation at hand. Every
part of the ritual embraces this directive, every exercise is designed to reinforce
it, and all discussion conforms to it—and once the retrospective starts,
the fear disappears as the collective story is told. DHQ:
Do you have to be a psychologist—or a referee—to serve as a facilitator?
How can companies identify internal candidates for the role of facilitator?
A retrospective facilitator needs to be a good listener, and should not have
been involved in any way with the project. The facilitator also needs to have
a passion for establishing continuous learning rituals, such as a retrospective.
My book gives many ideas about how to develop facilitation skills. Experience
leading retrospectives is more valuable than a psychology degree or a mediator's
license, though many retrospective facilitators study these areas. A new
facilitator can get experience by starting with simple retrospectives of small,
successful projects in which team members enjoyed working together. When more
difficult retrospectives come along—those that involve project failure, cost
overruns, serious schedule slips, people hating each other, and so on—it's
best for new facilitators to partner with a facilitator who has had more experience
managing a group's emotions. It's important that the facilitator understands
the vocabulary and the various jobs involved with the project. I know about software
and hardware projects, so I'm good at facilitating retrospectives of those projects.
Some projects, I won't attempt. For example, at the close of the O.J. Simpson
trial, some friends suggested that I lead a retrospective for the prosecuting
attorneys, but because I know nothing about murder cases, I rejected the idea
before it became serious! DHQ: Why should companies hold
retrospectives of failed projects, when they need to know how the successful projects
worked? A successful project may only be a lucky project
with all the factors for failure waiting to come into alignment. With a failed
project, it's clear something needs to change, usually many things. Every failure
I have looked at has led to changes not only to the team's process but also to
the entire company's procedures. I remember one retrospective held for
a team that had suffered a major failure. Over a three-day period, the members
of this team shifted their self-image from "Oh no, we are failures,"
to "Given the situation and the culture, we did very well; in fact, we've
learned some very important things." They invited the vice president
of IT to join them for the final session, and they explained to her that during
the course of events, they had learned 23 practices that either would have prevented
the failure or at least made it apparent earlier in the project. The team leader
went on to tell the VP that no other software project in the company was doing
any of these 23 practices. DHQ: In a systems or software
development department or organization, who would most benefit from reading Project
Retrospectives? Wisdom is the learning that comes from
experience, and project retrospectives ooze wisdom. In a retrospective, new managers
have a great opportunity to learn firsthand what's important in running a software
project in their environment. No popular project management book can be as relevant
or as valuable. Beyond new managers, many participants will benefit: patterns
miners, software-engineering process groups, quality-assurance leaders, change
agents, and incoming senior managers—along with vice presidents, chief information
officers, and so on. Then, of course, we must include anyone who wants
to learn to do his or her job better. DHQ: If you had to
choose one lesson from Project Retrospectives that you would like
the reader to take to heart, what would that be? The more
you don't want to do a retrospective, the more you are likely to learn from it.
DHQ: How did you go about developing
your Prime Directive? Was it inspired by any specific event?
Years ago, I was reading a selection of the letters Gandhi wrote to his adopted
daughter, and I was trying to learn how this great leader and pacifist was able
to live by his values while interacting with the British. After one horrid incident,
he wrote something to the effect that, in spite of their actions, they are doing
the best job they know how to do. It was Gandhi's intent to help them learn how
to do a better job. Gandhi's philosophy struck me as a profound wisdom
that applied to many parts of my life, and very naturally shaped how I designed
a retrospective ritual. DHQ: What keeps companies from
holding a retrospective of each project? Three things:
(1) habit, (2) the lack of awareness that retrospectives are important, and (3)
the inability to find an experienced facilitator. With this book, the ritual is
now legitimate and publicized. Teams are asking for retrospectives, and as a result,
retrospective facilitation services are rapidly becoming available all over the
world. DHQ: What kinds of projects merit a retrospective?
I think every project deserves a retrospective—there
is always something to learn, to improve. Even a perfect project needs a retrospective
to see if there is something someone did that no one realized contributed to the
perfect outcome. This includes one-person projects—I held a retrospective
for myself on writing a book on retrospectives and learned a great deal. DHQ:
In Project Retrospectives, fables and cartoons illustrate a number
of the points. How did you arrive at this teaching style?
A facilitator needs to be able to recall many aspects of this book "on-the-fly."
To that end, I've used mental triggers, such as a cartoon or a fable, to enable
many different recall mechanisms. I was writing this book while my partner was
working on her Masters Degree in Adult Education, and over the dinner table, she
would discuss the theories of how adults learn. I'd be up at 4:30 the next morning
trying her ideas out in my book. DHQ: What inspired you
to use a "cookbook approach" to teach people about retrospectives?
Our field has too many gurus ready to offer the one true way to build software.
I don't buy into such methodologies, and I avoid making that kind of mistake in
my book. There is no one right way to facilitate a retrospective. I find I need
to tailor every ritual to the project and to the team. Given this reality, I offer
many exercises in the book to empower each facilitator to pick and choose as appropriate.
This is what a real cookbook is—a bunch of recipes that allow the cook to
decide what dishes are best for his or her guests. DHQ: What
inspired you to become involved with retrospectives? As
a kid, I raced sailboats. It is a sport with some danger involved, and occasionally
someone would die in an accident. I watched adults, for whom I had a great deal
of respect, fearlessly investigate entire races and every decision made by everyone
to see what could be learned from these accidents. I participated in retrospective
rituals in which the whole sailing community heard the story and discussed the
lessons. I saw how such a ritual could be held even amidst great emotions. I watched
as new practices were put into place to make the sport safer. Thirty years later,
every time I board a boat, those lessons are fresh in my mind. Has something
I learned in one of those retrospectives saved my life? It's very likely. DHQ:
Who in your field has been your greatest inspiration and why?
Jerry Weinberg has spent his entire career bringing the people element into
our new profession—at least it was new when his career started. Given that
most software is built by teams rather than by solo programmers, it's obvious
to me that understanding how teams work and learn is key. Readers of Jerry's books
will see that Project Retrospectives is a specific application of his general
principles. DHQ: What do you wish you had known when you
started as a retrospectives facilitator? I had to learn
that it was okay to ask for help if I didn't know what to do next during a retrospective.
Asking the community for which you are facilitating for help on how to proceed
is (a) okay, (b) likely to yield great ideas, and (c) likely to add to your own
learning. DHQ: What kinds of training and consulting services
does your firm, Elite Systems, provide? My firm facilitates
retrospectives, of course, but more importantly, we like to partner with inexperienced
facilitators to help them master the techniques. While some people think
of a retrospective as a ritual that happens at the end of a project, it's also
a ritual that happens at the beginning of another project. There are a number
of services that my firm provides to help install the changes identified in the
retrospective, including specification and design methodologies, software architecture,
quality assurance, requirements gathering, project management, reuse, and configuration
management. Of special interest is working with a team that has recently
experienced a failed project, as the potential for improvement is so great. DHQ:
Rumor has it that you reside on the water. Tell us about your houseboat.
I am very fortunate to live in Secret House, a three-story Victorian floating
home located on the Willamette River in the middle of Portland, Oregon. My 1965,
33 foot Columbia sailboat rests alongside my house, ready to be sailed with five
minutes of preparation. If the wind isn't perfect, then I can take my kayak out
and watch the blue heron, beaver, osprey, salmon, and if I'm lucky, a bald eagle.
The name Secret House was given by the previous owners because it has secret
panels throughout. How many hiding places does it have? No one knows, but so far,
I've found five. DHQ: Thanks, Norm! | 
