Category: Retrospectives

  • Check-in in a Circle

    When I kick off a class or workshop, I want participants to engage as soon as possible after entering the room. I do work through some practical bits first, but after that I quickly hand things over to participants.

    For a long time, I’ve been using an opening exercise I learned from Ken Schwaber. In it, I ask participants to sort themselves along a line in the room, according to different criteria.

    First, I ask the group to sort itself according to how effective and efficient their current project is (in Swedish, a single word has the connotation of both “effective” and “efficient”). Once sorted, people take turns sharing their situation. Doing this, participants come to see what a wide range of different experiences are present in the room.

    After this, participants get to sort themselves again, this time according to the level of energy they perceive in that same project. Really low energy in one end, and high in the other. We talk about it again.

    Finally, we do the same thing, this time based on how much experience and knowledge of Scrum the participants feel they have.

    Earlier this summer, I participated in a terrific one-week workshop with organizational development pioneers Charles and Edie Seashore. The name of the workshop was “Intentional Use of Self”.

    In one part of the workshop, we talked about how check-ins are an important part of helping a workshop group come together. We also did check-ins every morning. One format we used was based on a fishbowl. Charles and Edie would ask one small part of the group to step into the middle, and tell each other about some thing.

    Today, I decided to try this format out. I asked people in the class to step into the fishbowl based on how long they had been using Scrum.

    First, I asked those with no experience to step in and talk to each other about their current situation and their expectations for the course. After that, those with a few months of experience got to share. Then those with up to a couple of years experience.

    Finally, those of us with longer experience (I joined the fishbowl myself here) stepped into the inner circle a told each other about our experiences and expectations.

    Here’s what I like about Charles’ and Edie’s check-in:

    • Participants face each other, not just me
    • In a circle, it’s easier to speak up
    • When you do speak, you speak with a smaller group
    • Everyone else can still hear you
    • The fishbowl circle puts more emphasis on the likenesses we share, whereas the line creates an exposed situation for those on the ends of a line.
    • We still get to see the different experiences available in the group

    It’s a simple but powerful check-in format. I’m fascinated by the fact that I had to travel half-way around the world to pick it up. I’m glad I did.

    Do you facilitate workshops or teach classes? Do you use check-ins? What kinds of check-ins have you tried so far?

  • There’s Always One [Drop|Comment|Question] Left

    My childhood friend’s mother was a “dagmamma”, literally, a “daytime mother”. In other words, she took care of a bunch of other people’s kids in her own home.

    She was a very kind and intelligent person. One of the things she said has stuck with me to this very day.

    “There’s always one drop left.”

    She would say this when we had had finished our “fika” (for kids in Sweden, this would be strawberry juice and cinnamon buns) and we would start playing with our empty glasses. Or rather: we thought the glasses were empty, but she knew better. That’s why she reminded us.

    I think of this every now and then when facilitating a meeting or a workshop. Whenever you ask for comments and questions, there comes a point where the contributions start to taper off. Silence commences. This is where you as the facilitator or convenener should stay quiet, too. Because, to paraphrase the wise dagmamma:

    “There’s always one comment left”

    Keep quiet. Count to twenty in German *) to focus your attention on something other than the heavy silence, and lo and behold. One more reflection always pours out.

     

    *) Silently, that is. If you experiment with counting loudly in this situation, let me know what happens. I haven’t tried it yet.

  • Use Improvement Stories to Make Your Retrospectives More Effective

    <plug>I teach a one-day class on retrospectives. It’s in Swedish only for now, but if that’s not an obstacle, you should read about it on the Citerus web site.</plug>

    I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a <type of user>, I want to <do what with the product>, so that <this value will come about>. There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement.

    Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.

    If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.

    These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.

    Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.

    An improvement story is quite easy to write, and looks like this:

    Because <description of problem or situation>

    we should <description of suggestion>

    so that <description of desired result>.

    I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.

    Have you tried using improvement stories? Drop me a note in the comments section!