|
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!
|
