Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

The Dorset House Quarterly Interviews

Norman L. Kerth
Author of Project Retrospectives: A Handbook for Team Reviews

ISBN: 978-0-932633-44-6  
©2001  288 pages   softcover  
$33.95 (plus shipping)

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!

AddThis Social Bookmark Button





COPYRIGHT NOTICE: The material contained in this file may be copied or distributed freely, provided that the material is copied or distributed in its entirety, including this Copyright Notice. This material is Copyright © 2002 by Dorset House Publishing Co., Inc. No use may be made of the material without acknowledgment of its source: Dorset House Publishing Co., http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.






New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044

Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal