Jake was pinned to his seat by the spotlight's intense beam. "Where were you when the code check-in introduced four P1 bugs?"
"I, uh, what?" Jake stammered.
I spun the spotlight and speared Bob with its white light. "The requirements document failed to take into account the Fergusson account. Why?"
Bob shifted in his seat. "It was Jane's fault, she didn't file a sales report for Fergusson!"
Jane's mouth dropped open and she reached for her cellphone. Somehow I didn't think she planned to text Bob with it. Not from the way she was holding it over her head.
Now I was getting somewhere. This post-mortem was finally getting to the bottom of things.
But before I could turn the spotlight towards Jane, a figure leaped onto the table and blocked my view. Jumping back, I looked up at the strange visage before me. Yards of red satin swirled about, all but obscuring the figure beneath it. A red galero covered the figure's head, its deep crimson so dark it nearly blended with the black hair that lay beneath it. The darkness of satin and hair offset the brilliant white teeth of my interloper, making him suddenly recognizable.
Hogarth struck a preposterous pose and declared, "No one expects the Gorilla Retrospective!"
The Post-Mortem:
If you have ever sat through a grueling multi-hour project post-mortem, you probably wished for the inquisition to sweep in and put you out of your misery. The very term means "after death." What a delightfully pleasant term for this meeting. Let us examine the corpse of the project and see what killed it. Let's not trouble ourselves with the fact that the project actually shipped and is a success. No, that would be pointless.
The purpose of the meeting is to tear apart the project and find everything that went wrong. As the project manager, you will assemble a mammoth document that goes into sickening detail. Even if you tell people "we aren't here to blame anyone", blame will be assigned and buses will be thrown on top of people (or something like that).
And when it's all over, the report is dutifully filed in some file cabinet (real or virtual) and promptly forgotten. No one goes back and reviews it. No one wants to remember the painful experience of exhuming a successful project for failures.
A rose by any other name:
Okay so we won't call it a post mortem. How about lessons learned or a retrospective? Yeah, that's the ticket. Now who's fault was it that we shipped with no user documentation?
You can slap lipstick on the pig and it will still be a pig. Changing the name of something, but not how you go about doing it, is just going to make folks dislike the new name as much as the old.
So many companies look back on their projects to find what went wrong and fail to try and do better the next time.
Break off that rear view mirror:
I've met no small amount of people who think the George Santanya quote "Those who cannot remember the past are condemned to repeat it" means we have to live in that history. Relive every mistake and wrong to determine exactly why it happened.
Not so. The horses are already out of the barn. Grilling the ranch hand on why he left the door open isn't going to do much. It doesn't get the horses back and it doesn't really do anything about the future. Manager Tools recently did a podcast called "There is no why in feedback." The Feedback Model is a manager tool for communicating about both the good and not so good things your directs do. The big key to it is that it doesn't focus at all on the past behavior. It just focus on the future.
An example:
"Don, can I give you some feedback? <wait for answer> "When you are late to the meeting, we start late and can't finish the agenda. This means not everyone gets a chance to be heard. Do you think you could change that next time?"
Read the last sentence again. "Next time." The manager doesn't dwell on the previous issue, instead he dwells on it not happening again.
And that's the secret to a great retrospective. Focus on the future. Don't assign blame. Don't dissect every problem. Don't get lost in the spilt milk. Focus on doing better the next time.
Forward looking:
When I do a retrospective I pull out another tool from my Manager Tools bag. On the left side of the white board I write "What Went Well." On the right side I write "Things to Look At."
The latter is important and I always stress it. TLA isn't about blame, it isn't about why, it isn't even about negative. It is simply things we want to look at for the future. This can mean you end up with things people would generally refer to a "positive" on the Things to Look At side. After a good retrospective, I often have lines drawn from items on the WWW side to the TLA side. Things that were not part of the normal process, that had a good impact and the team wants to do it again.
The next step is to lay down the brain storming rules. When using the brain storming rules there is no "No", "But", or "I don't agree." Brain storming is a safe zone where anyone can throw out anything and there will be no discussion, no argument and anything goes. If someone yells out "Pepperoni Pizza," my only response is "Is that a 'Went Well' or a 'Things to Look At'?"
When you're done collecting your WWW-TLA you then give everyone something to vote with. Small teams can use markers, larger teams work well with stickers or even post its. Let everyone vote two or three times on the TLA side. Then you tally up the votes and you've got your top things to look at changing for the next time. Short, sweet, to the point and very effective.
Don't make your retrospectives a full court trial. Don't dwell on the past. Do make it safe for people to reflect. Do focus on the future.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP
Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.
Posts
