Management Consulting
Project Jump Start
Management Coaching
Workshops AYE Conference
Project Management
Management
Hiring
Requirements
Consulting
Process Improvement and Quality
Managing Product Development
Hiring Technical People
Manage It! Your Guide to Modern, Project Management
Behind Closed Doors: Secrets of Great Management
Hiring the Best Knowledge Workers, Techies & Nerds
Corrective Action for the Software Industry
Amplifying Your Effectivess
Speaking Calendar
Testimonials
Resume
Contact
Book Commentaries from Reflections, Volume 5
Book Commentary:
Project Retrospectives: A Handbook for Team Reviews
Norm Kerth, 2001
Would you like to reduce your next project’s schedule by at least a week with no corresponding increase in staffing or defects, and with no decrease in quality, performance, or feature set? Too good to be true? Nope, just a case of learning from past project experience.
We all know we should review what happened on a project, using a project retrospective, but few of us do. In his book Project Retrospectives: A Handbook for Team Reviews, Norm Kerth covers not just how to facilitate a retrospective, but also how to sell one to busy team members and managers. Kerth breaks down the potential retrospective-buying marketplace into three segments: people who want to improve how they work and for whom change is a habit; people who’ve experienced pain or a crisis, and who recognize they need to change; and people who don’t particularly want to change, regardless of how painful their last project was. Kerth discusses how to sell retrospectives to each of these segments. In particular, Kerth discusses how to move people from the “I know we should, but we can’t afford it” to the group who will make time for a retrospective.
In reading this book, I most enjoyed the retrospective exercises. Kerth reviews how facilitators can build safety in the room, managing the “I’m too busy to participate in a retrospective” syndrome and how to define success in the retrospective. Two of the most powerful exercises for participants are the “Develop a Time Line” and “Emotions Seismograph” exercises.
Each person experiences a project differently. When you develop a timeline, people group together, by project groups, functional teams, or another logical grouping. Each groups is small enough so that all group members can participate. Then, each group identifies its significant events, one per index card. The group doesn’t have to agree on each event; if one person identifies that event as significant, the card is appropriate. When everyone has identified his/her events, each group places their cards on the wall in time line order. Once the cards are up on the wall, the participants walk up and down the time line to see how the whole project came together for the other team members.
Project milestones are not the only significant events. A tester might view as a significant event the day he had lunch with a senior architect and understood the architecture. A developer might select the day she handed off the build and smoke test procedure to the release engineer. A writer might remember the day he mastered a particularly challenging help text design. Because of our unique experiences, we all have different significant events.
These significant events and the times they occurred helps the project team answer the critical retrospective questions that Kerth poses:
- What did we do well that we don’t want to forget?
- What did we learn?
- What should we do differently the next time?
- What still puzzles us?
- What do we need to discuss in greater detail?
Some people prefer to ask the blunt question: “In hindsight, what incredibly dumb thing did we do and why?” Instead of berating ourselves, Kerth’s questions are designed to prompt us to think without making damaging our self-esteem. Retrospectives are to learn from our past efforts, not to berate ourselves for not having perfect vision and execution.
After people have had some time to review the time line, they are more apt to remember how they felt during the project. Although many of us don’t discuss our emotions at work, our emotions can prevent us from being successful in the next project. The Emotion Seismograph is very helpful in recognizing our emotional states during the project.
Above the Time Line cards, the facilitator draws two lines on paper to delineate the highs and lows of job satisfaction. Each person takes a marker and draws a line about how they felt about their job from the beginning of the project until the end. Kerth describes several techniques for how to do this anonymously with both small and larg groups. The Emotion Seismograph allows us to talk anonymously, and still recognize that we’re all people, with all of the feelings that people have.
Kerth describes many more exercises, all designed to bring out the learnings from the project. In addition, Kerth describes a post-mortem, what to do when a project has actually failed, i.e. money was spent and there’s nothing to show for it.
Kerth also describes a sample post-retrospective report, and techniques for dealing with the information in several retrospective reports.
The book is well-written, easy to read, and accessible, especially if you’re skimming the table of contents or index to investigate the next step for your retrospective planning. Use this book, and your retrospectives will return significant information and save you time on your next project.
Project Retrospectives: A Handbook for Team Reviews, by Norm Kerth. Publisher: Dorset House Publishing, New York. 2001.
Book Commentary:
Communication Gaps and How to Close Them
Naomi Karten, 2002
Several articles in this issue deal with making considering project tradeoffs. Once you’ve thought about the tradeoffs, how are you going to discuss them with your colleagues and management? If you’d like help assessing how you can be more successful in your communications, read Naomi Karten’s new book, Communication Gaps and How to Close Them.
Naomi first discusses numerous reasons that communications gaps occur: for example, we don’t verify with our recipients that they received the messages we sent; we don’t communicate what we wanted; we don’t know how to improve our communication skills; sometimes we just fall into communication gaps created by others.
Naomi discusses four kinds of communication gaps: everyday interaction gaps, relationship gaps, service gaps and change gaps. For everyday interaction gaps, I particularly enjoyed the section about how messages cause confusion. Naomi gives examples about the differences in spoken language, such as between British English and American English. Naomi’s examples reminded me of the first time I tried to discuss car parts with my English cousins – we took a few minutes to understand where to put the luggage (in the boot), and what to put into the gas tank (petrol).
Aside from word misunderstandings, Naomi discusses several categories of terminology misinterpretations: project, meeting, service, business, and everyday terminology. Naomi is generous with her examples and anecdotes, making this section readable and translatable to your situation. At the end of the misinterpretations section, Naomi suggests techniques for clarifying agreements.
I particularly enjoyed Naomi’s suggestions for how people can build a strong working relationship, Chapter 5, “Building a Strong Foundation.” On page 108, Naomi says, “Trust, respect, and understanding among colleagues don’t develop overnight, but the earlier in a relationship you start trying to create them, the fewer overnights they’ll take. Trust, especially, helps to build the foundation, but building the foundation can also strengthen trust.” Naomi goes on to give specific suggestions about how to start communicating in a new relationship. For example, if you are starting a project with a new team, or even just a few new people, take advantage of Naomi’s suggestions to: make contact, find common ground, laugh together, build rapport, establish group norms, manage expectations, develop understanding, make time to talk, and meet face-to-face.
The section on change includes alternatives to getting people to change. Since you can’t make people change, Naomi suggests you change how you communicate during change. Among her 14 suggestions are two I particularly like: allow people to vent and listen proactively. One of my clients, a VP of Engineering, was having trouble “getting” his middle managers to change during a substantial process improvement effort. When I suggested he listen to his staff explain their concerns about the change, he realized that his staff knew much more than he did about how to do their jobs. He started proactively listening, seeking out his staff members, and asking their opinions about how to do the work better. The process improvement progress moved from glacial to something happening every week.
Naomi has pulled together numerous examples of communications gaps and explained how to close them, whether you’re doing management, project, or service work. If you’re trying to choose a communications technique, check out this book.
Communication Gaps and How to Close Them, by Naomi Karten. 2002. ISBN 0-932633-53-6, Dorset House Publishing. New York, 2002.
Naomi’s web site is www.nkarten.com.