nilswloka.com - A weblog about agile software development, coaching and strange ideas...

Designing a Facilitator training - Part 2

2012-02-29T00:00:00+01:00

In the first post of this series, I gave you an overview of the design principles and an outline of the actual workshop. Meanwhile I've been through a couple of iterations of the training. I incorporated a lot of valuable feedback and like to give you a little more detail on the current version. So in this part, I'll write about both the preparation and the first two sections of the workshop. Hopefully you will find this useful for your own trainings.

Setting the stage

Let's start with the preparation. I decided to use a flip chart for presenting the workshop's material instead of a slide deck for a more inclusive experience. To be honest, the first attempt could only be called a paper orgy. I now use two flip charts, one holding the prepared material, which I will describe in more detail when I write about the various exercises, the other being used for capturing the participants' input. This also allows me to reuse most of the sheets. If you go for a similar apprach, I suggest numbering all of the sheets to make it easier to produce a photo protocol afterwards. In reaction to feedback I received, I also hang up a sheet showing the agenda with a sticky note indicating the current item and an initially empty sheet labeled "Activities".

Having two or three mobile pinboards at hand won't hurt, either. I use those for displaying important results and to separate workspaces during the retrospective dojo. I also bring along my facilitator's toolcase, an ample supply of sticky notes and markers and of course candy bars.

When preparing the room, I arrange the chairs in a half circle facing the flip charts. Additionaly, there should be one table for every four or five participants for group work and the retrospective dojo. Talking of numbers, I've had good experiences with around 15 participants. With larger groups I felt pressed to stay on schedule. I am yet to facilitate the workshop with less than 12 participants and would be interested to hear whether the exercises work well with smaller groups.

As a last detail, be sure to explicitely mention that participants need to be familiar with the tale of Goldilocks and the three bears when writing invitations and bring a few printed copies of the story as backup plan. Ending up without a shared context when trying to do the Goldilocks Retrospective is no fun.

Reception and Introduction

After all participants have arrived and things settled down, I welcome everybody and explain a few organisational details. Stuff I mention includes:

The general outline of the workshop.
The breaks, as in my experience, people tend to feel less of an urge to check their emails during the training when they know in advance that the agenda includes frequent breaks.
The interactive nature of the training, including the invitation to ask whatever questions come to mind.
The material every participant will receive after the workshop.

Feedback from earlier iterations of the workshop suggests that the last point is really important with this format. As there are no hand-outs or slides and most of the content is collaboratively developed during the training, some participants haven't been sure whether they were supposed to take notes. Now I point out that I will prepare a photo protocol and a fact sheet the next day. There is also symbol on some of the flip chart sheets that indicates that further resources are available as part of the workshop documentation (cf. image).

Once the training starts, ESVP (Explorer, Shopper, Vacationer, Prisoner) from Agile Retrospectives serves as icebreaker. You usually get a few laughs when explaining the Prisoner role and people start talking. To avoid wasting too much time here, I distribute slips of paper marked with the corresponding letters before the training starts. I don't debrief this activity and instead follow up with my Check-In question, which I usually combine with a short introduction round: "Please introduce yourself and tell us in one sentence what needs to happen so that this workshop is worth your while.". I capture the answers on a flip chart and revisit them during the workshop when I think we developed ideas that relate to the participants' expectations.

In my usual audience, there is almost always someone who expects to get a good overview of what a retrospective should feel like. This allows me to lead over to the next section.

Goldilocks retrospective

I'd like to give credits to Sallyann Freundenberg for introducing me to this exercise at XP2010. It very elegantly solves the problem of not having a common context for demonstrating retrospectives.

The Goldilocks Retrospective serves multiple purposes:

It provides a good impression of what a typical retrospective might look like.
It allows me to model facilitation techniques for the audience right at the beginning of the workshop.
It is a laid-back exercise that makes it easy for people to overcome any initial reluctance to participate.
It is in itself a good template for a becoming facilitator's first few retrospectives.

The retrospective itself looks like this:

Set the stage with a very short introduction (5 minutes).
Gather data with a Timeline and use a Dot Vote to determine which event has the biggest emotional impact on the group of bears having the retrospective (20 minutes).
Generate insights with Brainstorming / Filtering. First, brainstorm with the question "What could be done to prevent this event?". Then, reduce the options by filtering with the questions "Would it really prevent the event you voted for?" and "Can we realistically do this?" (20 minutes).
Choose one of the remaining actions with another Dot Vote and refine it into a S.M.A.R.T. goal by asking "Who?", "What?", "When?" and "How will you measure success?" (10 minutes).
Close the retrospective with a +/delta by asking "What helped you to achieve this result?" and "What should I try next time?" (5 minutes).

As I want the attendees to get a glimpse of what it means to facilitate a retrospective, I go strictly by the book (e.g. no meddling with the actual content, careful time management, etc.). I also try to model facilitation techniques as often and as explicitely as possible and every now and then stop to explain what I was doing. I am especially careful with those parts that are easy to get wrong when you start facilitating retrospectives (too much interpretation during the Gather data phase, no concrete actions or no commitment, etc.).

At this point, everyone will have actively participated in the training. Some people will just have seen their first "formal" retrospective. It's time for the first break - remember the candy bars?

What's next?

In the next part of the series, I will explain how I try to help attendees to develop an understanding of the fundamental principles of a retrospective (Retrospective Prime Directive, double-loop learning, etc.). In the meantime, I'm looking forward to your feedback.

Code Dojo Extreme

2011-08-17T00:00:00+02:00

Among the things we brought with us from XP 2011, Robert Chatley's and Matt Wynne's Extreme Startup game sounded like the most fun. While I unfortunately missed the session back in Madrid, Christian, a colleague of mine, was extremely enthusiastic about it. So tonight, we gave it a try at our company internal Code Dojo. What can I say? I never knew that stress could be so much fun.

What's that thing about?

If you haven't heard about Extreme Startup yet, you can think of it as a programming competition. Participants register their own web applications at a Ruby-based game server, which will in turn spam the participants' application with requests containing all kind of questions. Every correct answer scores some points while wrong answers, timeouts or other failures are punished with a small amout of negative points. Scores are kept track of on a leaderboard served by the game server.

How does it feel?

Norbert and I were planning to implement our server in Clojure. I actually felt quite confident because turnaround time seemed like a major success factor and interactive development with Clojure excels in this regard. So I made some resolutions up front: I would of course write unit tests and use version control, maybe even do some TDD, which in Clojure I don't feel exactly comfortable with yet. The warm-up round went smoothly and we were looking forward to the real thing. Then the requests started rolling in. Rushing in! When the dust finally settled, we had lost a few hundred points and lots of sweat.

While things improved from there, it was not before the third round that what could only be described as frantic hacking turned into something I dare to call software development. It can be attributed to the Clojure REPL that we were still able to take and defend the lead until the game server died unexpectedly in round four. It goes without saying that I didn't write a single unit test nor committed a line of code to the repository before the end of the game (you can have a look at the result here).

So how did it feel like? Why, terrible, energizing, stressful and very funny at the same time.

Why should I try it?

While not exactly a realistic exercise, Extreme Startup will tell you a lot about what you don't yet feel completely comfortable with. Be it keyboard shortcuts, refactorings, language idioms or test-driven development, trying to write code with the other teams on your tail sure does a good job of exposing your weak points. Besides, you'll have a lot of fun, so I can only recommend giving it a try.

A little advice

If you consider hosting an Extreme Startup session yourself, this checklist might help:

Make sure that all participants have a skeleton project before joining or your warmup round might take longer than expected.
Tell the participants to check whether their servers can be reached from the network. We experienced all kind of weird firewall issues during our session.
Participants need to be able to write an application that responds to HTTP GET requests. You should also consider telling them that they should be prepared to parse strings.
Play through all rounds before hosting the session. Be prepared to deal with bugs in the game server.

Finally, I'd like to thank Matt and Robert for the awesome idea and for providing the game server!

Designing a Facilitator training - Part 1

2011-07-30T00:00:00+02:00

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

from Principles behind the Agile Manifesto

I believe that the ability to inspect and adapt is one of the essential assets of an agile team. When we discussed about what we could do to help our teams to improve this aspect of their work during one of our internal Open Spaces, we came up with the idea of enabling more of our colleagues to facilitate retrospectives in their branch offices. As I do a lot of retrospectives for the teams I work with as internal coach, I volunteered to develop a workshop to teach interested colleagues the ropes of facilitation.

The challenge

Now I'm convinced that neither coaching nor facilitation is something you can learn while listening to someone in the front of the classroom or by reading a book (even though Esther Derby's and Diana Larsen's excellent "Agile Retrospective: Making Good Teams Great" helps a lot). What I wanted people to actually walk away with was both some first hand experience and the feeling that this was the right way to help their teams grow . I decided to go for a one day workshop to make it reasonably easy to attend even for those colleagues who are busy with projects at our customer's sites and to keep the initial expenses low.

At the same time, I had to take into account the fact that many of the workshop's participants might have no prior experience with retrospectives at all.

Goals

So within those constraints, I came up with the following primary design goals:

Demonstrate why we should do retrospectives
Provide as much hands-on experience as possible
Make the role of the facilitator clear
Simulate some of the more difficult situations you might get into as facilitator

Additionaly, I considered it necessary to provide just enough "theoretic" background for the participants to help them understand the fundamental concepts of retrospectives.

I was also pretty sure that it wouldn't make sense to go into too much detail regarding actual activities, as there's a lot of good material available in book form and on the web.

Sources of inspirations

There were a few sources of inspiration I draw from for the first draft of the workshop. One of my first serious exposures to retrospectives was a two-day workshop with Jutta Eckstein some four years ago. One of the things I really liked was the way Jutta used a lot of retrospective activities to teach about retrospectives. This not only lead to lots of interaction, but it also allowed the participants to see a very experienced facilitator actually leading through those activities.

I was lucky to see another interesting way to introduce people to retrospectives when attending Sallyann Freudenberg's "Goldilocks Retrospective" session at XP2010 in Trondheim. In less than an hours, Sallyann "simulated" a complete retrospective with the participants playing the role of bears, who from various sources had just learned about the burglary at Family Bear's place and tried to devise a plan to prevent such a thing from happening again. While this session wasn't exactly targetting facilitator's, I very much liked the way it quickly illustrated the workings of a retrospective.

Last but not least, I was pleasantly surprised by how well the concept of Coding Dojo translated to coaching skills when attending the Coaching Dojo at Agile Coach Camp Norway earlier this year.

The first agenda

Some weeks, a few hundred index cards and a very helpful discussion with Rachel Davies and Paul Carr at said Agile Coach Camp later, I came up with the following plan:

Reception and Introduction

Trying to involve the participants as early as possible, I decided to start with a very short reception followed by the ESVP (Explorer, Shopper, Vacationer, Prisoner) activity from Agile Retrospectives. I also decided to skip the traditional introduction round in favour of another retrospective activity I often use for setting the stage and decided to follow up with a Check-In during which each participant would give a one-sentence answer to the question "What needs to happen in order to make this a successful day for you?".

Goldilocks Retrospective

To make it easier for those colleagues with no prior exposure to retrospectives to follow along, I would then introduce the basic concept by means of the aforementioned Goldilocks Retrospective.

Ball Point Game

When thinking about how to best demonstrate why we should do retrospectives, I remembered the Ball Point Game Boris Gloger uses to illustrate the principles of Scrum. It occurred to me that by focussing on the breaks between the actual iterations during the debriefing, both the reasons for and the goals of retrospectives should easily become clear.

Essentials of a retrospective

With all the action going on during the first hours of the workshop, I felt that a change of pace was needed to let things sink in and decided to conclude the morning with some theory. The topics I planned to discuss with the participants included:

The Prime Directive
The four key questions
Attendants and occasions

Role of the facilitator

Fun fact: In German, 'Rolle' is a homonym
meaning both 'scroll' and 'role'.

To get things going again after lunch break and to provide some hands-on training, I came up with a variant of Scrum from Hell. I assumed this would most probably lead to a discussion about moderation and facilitation techniques, for which I prepared a few examples.

I also planned to address the following topics in this part of the workshop:

Planning a retrospective
Debriefing activities

Structure of a retrospective

Following the rationale mentioned above, I kept this part of the workshop to a minimum and basically just prepared a few flip chart sheets summarizing the activities used during the workshop and introducing a few new ones to be used during the last part of the training.

Retrospective Dojo and Closing

Building upon the concept of the Coaching Dojo, I figured that it would be good idea to close the workshop with what I called a Retrospective Dojo. I prepared two different retrospectives, both with a topic all of the participants could relate to, and some rules dealing with facilitator rotation and giving feedback, planning to let everybody experience the role of a facilitator in a real retrospective.

I would then close the workshop with a feedback round after having the attendants summarize their impressions from the Retrospective Dojo.

To be continued

In the next post, I will desribe the workshops content in a little more detail and let you know what I learned during its first implementation. In the meantime, I'd love to hear about your experiences with teaching or learning how to facilitate retrospectives. What worked well for you and which traps did you fall into?

Keep the timeline tangible

2011-07-15T00:00:00+02:00

As internal coach, I get to facilitate quite a lot of retrospectives. While most go smoothly, every now and then teams seem to get stuck when trying to analyze their data. As I design most of my retrospective based on the phases proposed by Esther Derby and Diana Larsen in their excellent book Agile Retrospectives, I tried to find out what might have gone wrong while Gathering Data.

Intangible Timeline

While reflecting about some retrospectives that felt awkward for the team and me, I noticed certain similarities. The most apparent pattern I came upon was what I like to call Intangible Timeline. Intangible timelines leave the team without any real input for the Generate Insight phase. Either everything seems already analyzed yet no conclusion is possible or everything is so abstract that you would actually need another Gather Data phase to make sense of it.

Let me give you some examples of what kind of data can make a timeline intangible and what you can do about it as facilitator:

Non-events

These are the post-its that usually end up above, below or to either side of the actual timeline because they don't really fit in. They represent ongoing or repeating "facts":

The customer keeps ignoring our emails.
My computer is too slow.

While these statements might be patterns that will come up when analyzing the timeline, accepting them as actual data might hide more important issues. When someone puts a non-event onto the timeline, I now ask questions like these:

What makes you think that the customer ignores your emails?
When did you notice that your computer is too slow?

Ideally, this will lead to tangible data:

Sent mail with questions about the business rule to Mr. Johnson, but never received an answer.
Running the full suite of integration tests after merging in Paul's branch took 4 hours.

Judgemental statements

While the Prime Directive, the team's working agreements and an observant facilitator will usually be enough to prevent blame and finger-pointing, there are more subtle forms of judgment. Have a look at these examples:

Too much time wasted at the weekly status meeting.
Lost a day fighting the complicated JavaScript library.

Too many of those can easily lead to premature or unsuitable actions being discussed. Try to find the real events by asking questions like these:

Why did the status meeting feel like a waste of time for you?
What was so difficult that it took you a whole day?

Aim for answers like these:

With the critical bug not yet fixed, I felt that I should rather be coding than sitting in the status meeting.
I haven't found any documentation on how to create the dialog box for feature X and needed almost six hours to figure it out on my own.

Low Resolution

Have you ever ended up with a timeline consisting of ten post-its with two words written on each? That's a low resolution timeline. Typical example events are:

Sprint planning meeting
Release of version 1.4

There is not much you can actually do with this level of granularity. Relevant information and controversial opinions are hidden behind a summary that everybody can agree with. Try to dig deeper with questions like these:

Why do you remember this particular sprint planning meeting?
What was the most important observation you made during the release?

There might be hidden treasures:

During the last sprint planning meeting I felt like you were ignoring my concerns about the ERP system's interface when deciding to include feature Y into the sprint.
When releasing version 1.4 we had to start over twice because the automated schema migration failed on a certain table.

Thought-reading

Thought-reading happens whenever someone assumes the perspective of another person while describing an event:

Mrs.Jones didn't like the new UI design.
We were frustrated by the low velocity.

This is a recipe for speculation, misinterpretation and generalization that can easily be avoided by asking about the actual observation:

What makes you believe that Mrs. Jones didn't like the new UI design?
Why do you think the others were frustrated by the low velocity?

Speaking for themselves, people will mention events like these:

I overheard Mrs. Jones telling Mr. Smith that it takes her twice as long to do her work after the UI redesign.
Last monday, Fred and Jim mentioned how frustrated they were with feature Z taking so much longer than our estimate. We discussed the situation, but I still felt like we needed to take some action.

Conclusion

I'm sure there are many other examples, but these categories I came upon quite often. I noticed that teams were able to produce a more detailed picture of their project when I kept asking those questions. What might have passed as one big event became a series of diverse observations. I also noticed that there seems to be a natural tendency towards Intangible Timeline as we are trained to analyze and interpret the world around us. As facilitator, I now try to be aware of the patterns I described in this blog and combat them with open questions when necessary.

Have you noticed similar patterns in your retrospectives? How do you react as facilitator? Feel free to leave a comment if you have a story to share.

Open Spaces within the company

2011-07-08T00:00:00+02:00

At the consulting company I work for, we have quite a few regular meetings to exchange ideas between collegues who otherwise spend most of their time at our customers' places. Recently, we started employing Open Space Technology at a few of them and received great feedback, so I'd like to share the story with you.

Expert forums

To facilitate knowledge transfer and communication between technical experts across our branches, we have an institution called expert forum. Every other month, every branch office sends one or more of their experts in a given field to discuss current topics and to identify need for action. With some ten colleagues attending that meeting, you wouldn't consider it a natural candidate for the Open Space format. Due to particular constraints, we tried it nevertheless and so far found the results encouraging. Here's the way we organize our expert forums:

With only a few participants and a single day of discussions, we felt the need to allow for some preparation in advance, so we basically moved the opening to our company wiki. Sessions are usually posted well in advance of the actual meeting to facilitate identification of additional participants.

Being preceded by status and project reports, the actual Open Space usually takes the second half of the day, with two or three sessions happening simultaneously.

As the expert forums have the goal of identifying need for action, a common outcome of the sessions is the plan for an experiment or very small internal project. The meeting is attended by at least one decision maker with budget authority. During the Open Space's closing, actions and project sketches will be presented by the sessions' hosts. Because we aim for S.M.A.R.T. goals, budget can usually be allocated directly.

This has led to some interesting initiatives, ranging from the design and implementation of retrospective facilitator trainings (which I have blogged about here) to the founding of an application lifecycle manangement task force.

I like to think about this form of Open Space as a market place of ideas, so if you are confronted with a similar situation, you might want to give the format a try.

Division meeting

When using the Open Space Technology at our latest division meeting, the goal was entirely different. With some forty consultants attending a meeting scheduled for the evening hours, we wanted to try something beyond your typical mind-numbing Powerpoint orgy. While we already had some success with unusual presentation formats like Pecha-Kucha, we always felt that the most interesting discussions occurred at the dinner following the actual meeting.

Thus we decided to merge dinner with meeting and have an Open Space and sandwiches at the same time. As we weren't quite sure which level of participation to expect with this being the first Open Space for many of the colleagues, we prepared some sessions beforehand.

We ended up with three simultaneous sessions, lots of energy and great feedback and will certainly stick with the Open Space format for our division meetings.

Apart from the vivid discussions, it significantly lowers the threshold for active participation and added a lot of diversity to a meeting that threatened to become stale.

Summary

These are only two examples of how to use Open Space Technology inside a company. We found that it works exceptionally well even with a small number of participants and we will surely explore other areas of application. If you have held Open Space style meetings in a corporate context, I'd love hearing your stories, so feel free to comment down below.