Recently, I read an interview between Bernie DeKoven (who has aliases as varied as: Major Fun, The Shaman of Play, and more) and Barry Joseph (Associate Director For Digital Learning, Youth Initiatives, at the American Museum of Natural History). While the whole interview is delightful, and I recommend it, I was particularly struck by the game called “The Out Blessing Game” or “Endless Blessings.”
We’re happy to announce that FutureWorks Consulting staff, Willem Larsen and Diana Larsen, have published a new book through the innovative, interactive publishing service Leanpub. The Leanpub story is interesting in itself, and we hope you will check it out. But more about the book!
Steve Berczuk writes a short and succinct article on TechWell describing, “Why Agile Retrospectives are Important in Software Development.” I’m looking forward to reading the comments and responses he gets. More and more I think of Agile Retrospectives as an opportunity for the kind of learning that leads to real adaptive action in complex situations.
Over at her “Insights You Can Use” blog Esther Derby has posted two pieces on how teams can benefit from the lens of Double Loop Learning in their retrospectives.
In a article at the Six Sigma IQPC site, Christian Loyer offers a new twist on the old fishbone diagram root cause analysis approach.
Martin Jul writes about a retrospective activity in the post “Retrospectives - Adapting to Reality.” He describes an interesting process for highlighting issues in the Generating Insights part of a retrospective session.
I’ve used “Park Bench” at the end of workshops as a way of reflecting on the day or as a debriefing technique after a training exercise to uncover group discoveries. You may be surprised that I hadn’t thought of it for retrospectives. I was. Luckily, Michael thought of it.
Sometimes teams get stuck at the point of “deciding what to do” in retrospectives. Team members may begin to point fingers and describe things that the ubiquitous “they” must do before the team can move forward or make improvements,. This may lead to a team-as-victim, “poor us, we’re stuck” syndrome, or blame and finger-pointing. “It’s their fault we’re in this mess!” Blame kills retrospectives and the perception of persecution stalls any hope of forward motion, so the retrospective leader has to shift this conversation, and fast! Team members also may perceive so much room for improvement they become paralyzed and can’t decide where to start improving their lot.
When victim-talk, blaming or overwhelm surfaces, I reach into my retrospective leaders toolbox and pull out a technique to help teams identify the kinds of action the team can take.
In a comment on an article about Pixar in The Economist, Tom Agan from the Nielsen Company, writes:
"At The Nielsen Company we have just completed a study of the major consumer packaged goods (CPG) companies operating in the U.S. and those with standardized post mortems for new products, like Pixar, average almost 100% more revenue from new products compared to those that don't...I think through articles like this and new research that quantifies the impact, we are coming much closer to uncovering the universal truths of innovation."
I'm willing to put up with The Economist (and Pixar)...
In Agile Retrospectives: Making Good Teams Great!, Esther Derby and I include a collection of activities we called, “Short Subjects.”
After Gathering Data, these useful activities provide relatively quick ways to review event, effort, and response data; reflect on the implications of the data; and Generate Insights about team experiences.
Nick Oostvogel describes a creative activity to revive boring retrospectives and tell the shared story of the project (Gather Data). He calls it Mr. Squiggle.
Deborah Hartmann posted a description of an interesting “Gathering Data” activity. She calls it “Draw Me a Picture”. It sounds like it would be fun and potentially quite insightful. I’m looking forward to trying it out soon. Thanks for sharing it, Deb!
In a recent Sticky Minds column, Naomi Karten writes about PMI (Plus/Minus/Interesting), a technique for helping groups think together about many aspects of an issue.
Jack Milunsky wrote about the Top Ten Activities of a Product Owner. In reply, a number of folks commented that they didn’t like the idea of a Product Owner attending Sprint Retrospectives.
Doc List writes about one of my favorite activities on his blog, Circle of Questions. I added a few comments there as well.