Running a World Café

This is a brief summary of my experience of running a World Café.

I volunteered to run a World Café, themed around Organisational Impediments and how to solve them, for my local agile Meet-Up group ‘Brisbane Agile’*

I deliberately kept my preparation to a minimum. I held some discussions with the Meet-Up Organiser, regarding how we would run the event and set up the room. Apart from that I created a few wall charts to help smooth out proceedings and came up with some sample Organisational Impediments. These were a backup in case the participants were reluctant to volunteer their own items for discussion. This word document contains the wall charts I used.

We set up the room with five groups of tables that seated about six people each. Seating for thirty people was wishful thinking, by the start time we had two full tables. The low numbers were probably due to the event being event in the Christmas season.

While guests were entering and eating the free pizza, I wondered around introduced myself. Asking what had brought them here and suggesting that they post their question or topic on the provided wall charts. From member I think we ended up with eight topics being suggested by the participants.

After brief introductions from our sponsor and the meet-up organiser, I got everyone on their feet and used dot voting to select two of the eight suggested topics. There were a couple of clear winners, which made it easy to start the two tables discussing each topic.

As a group we decided as a group to drop down to ten minute discussion rounds. This allowed us to get through four topics in total.

I time boxed us to ten minutes of discussion, followed by a couple of minutes to switch tables and then another ten minutes of discussion. The conversations that occurred where very animated. It was a real struggle to stop them and get us on to the next round. After the first topics had been discussed by both groups we had the topic leader provide a quick overview which sparked even more discussion.

With roughly half of our planned time used up we used dot voting again to select another two topics and do it all again. Again we had very energetic discussions, which were constrained by the ten minute boundary.

The result was these sheets of butchers paper, which fail to convey the excitement and energy that was in the room.

Result: Agile Contract Models

Result: Introducing Agile into a large organisation

Result: What is more effective Scrum of Iterative Waterfall and Why?

Result: Agile estimation

We ended up with some very satisfied attendees. Some left with a much better understanding of agile, another walked away with an action plan for how he will sell agile to the management group in the company he has just joined. Everyone seemed to walk away happy.

I whole heartedly recommend you to run your own World Café; it is easy to set up, exciting and harness the energy of the participants.

*At the time of the World Café it was actually a separate group ‘Brisbane Scrum and Agile’ Group, however it has since merged with the ‘Brisbane Lean and Agile’ group to become ‘Brisbane Agile’.

Photo by: Travel Fools of America 

Top tips for Retrospectives

Tip: Change ‘Five Whys?’ to ‘Five What Caused that?’

“No problem can be solved from the same level of consciousness that created it.” Albert Einstein 

This quote is one of the many reasons why I am a big advocate of using the Five Whys techniques in Retrospectives. My experience shows me that finding and then fixing the root cause has a much longer lasting effect then fixing the reported problem (aka symptom). While the Five Whys technique is great; there a little twist that can make it even more effective for new teams.

Teams are new to Retrospectives find it a big challenge to raise issues that they are used to ignoring or hiding. Creating an environment where they feel safe to bring up issues is critically important for the success of the Retrospective.

‘Why’ is a word that puts people into a defensive state of mind.  As it focuses the respondent on their own involvement in the issue and hence, they are inclined to play down the issue for fear of making themselves look bad. Hence I prefer to phrase the Five Whys as the Five ‘What caused that?’ Using the word ‘what’ takes the focus off the respondent and lets them look at the issues that caused the symptom. This allows them to stay in a problem solving state of mind as opposed to a defensive state of mind. 

Lastly when looking at a tough problem, writing up the Five ‘What caused that’ items on a whiteboard as the team discusses the issue helps to give the discussion focus.

Tip: Validate the input of all attendees

One of the most effective techniques for creating a safe environment in Retrospectives is a simple one; validate the input of all attendees, especially the quiet people. What I do to validate their input is summarised in these points:

• Validate each idea that is raised by either reading the idea aloud or repeat back the idea that was raised verbally.
• Treat all people and ideas equally (even if I strongly disagree)
• Keep the Retrospective to one conversation at a time so that everyone is involved in all of the discussions.
• Specifically ask quiet people what they think about issues under discussion.
• Support quiet people to get their ideas across when they do voluntarily speak up.

Tip: Prioritise and cluster

The Retrospective format that I most often use is ‘Puzzle, Problem, Try, Keep’ from Agile Retrospectives by Esther Derby and Diana Larsen.

Starting the Retrospective with five minutes for participants to write up their thoughts onto Post-it notes in silence is a method that allows everyone to provide their own unique input without being influenced by other participants. I suggest one thought per Post-It note, as it makes arranging and discussing each thought much easier. You can stick the Post-Its notes into the Puzzle column to begin with and it is usually a good idea to cluster similar thoughts.

Image 1: The teams ideas clustered in the Puzzle column by theme

With the initial thoughts clustered into the Puzzle column any important issues will stand out as a big clump. If you have lots of separate thoughts, it will be worth asking the team if there are any burning issues before proceeding. 

With the large clusters and burning issues identified you now have a set of thoughts to address first.

Tip: Use a workflow

I see the ‘Puzzle, Problem, Try, Keep’ Retrospective as a workflow. Thoughts start out as Puzzles and either stay there or move to be a Problem. Problems link to Tries. Tries from previous Retrospectives were either successful and hence become a Keep, or need to be re-tried or are dropped. In general this results in a left to right workflow.

After gathering the Thoughts of the participants into the Puzzle column it is always worthwhile discussing the Tries from the previous Retrospective. Was the Try successful and hence should become a Keep. Did the Try have issues that we think we can overcome; hence it stays as a Try. Is it an abject failure, hence dropping off all together? Discussing previous tries shows the team that Retrospectives are for delivering outcomes not just suggesting Tries that are never followed up on.

Image 2: The Try's from last Retrospective being reviewed and placed accordingly.


Now it is finally time to address the new thoughts. I suggest discussing each thought in turn.

For puzzles and problems, use the ‘Five What Caused That?’ approach to identify the root cause, aka Problem. Once it is clear that you have a Problem move the Post-It to the Problem column and list the root cause.

Image 3: Put the top priority discussion topic into the Problem column and noting its root causes.


With a Problem in the Problem column that is well understood and it has a root cause identified it is time for the team to recommend one or more Tries. These are written in the Try column and you should draw arrows from the Problem to the matching Tries. The arrows represent cause and effect, ensuring that we put effort into Tries that will have some lasting impact.

Image 4: Linking the Problem to its Try's.

For thoughts about things that went well, or items you should keep; be sure to discuss with the team why it was successful and how we can ensure it will be successful again in the future.

Tip: Find the Problem that Tries are attempting to solve

Often participant’s thoughts will be suggestions for Tries, e.g. ‘Run the tests in parallel’, or ‘Use Gradle for our build process’. In this case it is very important to understand what Problem they are attempting to solve before just adding the Post-It note to the Try column. You can use the ‘Five What Caused That?’ approach to ensure that you attempting to solve the root cause.

Image 5: What the board could look like at the end of a Retrospective.

Tip: Make sure Tries are turned into action

I have seen several teams that where good at coming up with Tries, yet were poor at acting on those tries; hence they did not improve as fast as they could have. The reasons for the lack of action were many and varied. Here are a few of things that I have found to help teams follow through on their Tries. They can be used in isolation or in combination.

• Assign a single person as an Owner of each Try during the Retrospective.
• Display the list of Tries near the teams Task board.
• Create a Task cards for each Try and put it on the Task board.
• Discuss the progress of each Try during Daily Stand ups.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Project Retrospectives