Books, Conference et al., Meeting Facilitation

Gamestroming Retreat

We need to collaborate more within our teams, with our managers and with our customers. Books like Gamestorming (David Gray) and Innovation Games (Luke Hohmann) or websites like and foster fresh practices for facilitating innovations when gathering in meetings or workshops with others. Last week-end I took part in a Gamestorming Retreat at The Hub Vienna.

Like a Code Retreat the Gamestorming Retreat is a day-long, intensive event focusing on enhancing your skills as a facilitator using the practices mentioned above. It is not about getting to know those practices, but rather to intensify on how to use and practice those while getting lots of feedback from the other participants.

The event in Vienna was facilitated by Michael Lausegger (@michael_lausser ) and Clemens Böge (@Beraterei_Boege), the about 12 participants came from different areas. The common theme for this Retreat was Team Development.

After the warm-up, Clemens and Michael shortly described the theory on one flip chart only:

Gamestorming on one flipchart

What followed was practicing this theory in three rounds with three practices:

I used and played all of the practices already before in workshops and retrospectives; still it was awesome to watch how others were facilitating and how different improvisations of the practice lead to different results or problems.

The Gamestorming Retreat Vienna was a great experience: It is helpful for everyone who wants to train her facilitation skills in Gamestorming and who wants to share her experiences with other facilitators.

If I was not living in Munich, I would definitely visit the next Retreat. Actually I’m thinking about organizing a Gamestroming Retreat in Munich. If you are interested, please contact me.

BTW: My team won the Marshmellow Challenge! 🙂

Meeting Facilitation

Agile Retrospective with LEGO® StrategicPlay®

Lucky I am, because I attended “StrategicPlay FUNdamentals on LEGO® SERIOUS PLAY™” about 2 years ago. (Read my post on it here.) My company was unbelievable and invested in the “Identity and Landscape Kit” afterwards and I had the chance to do a number of LEGO Serious Play (LSP) Workshops since (HR team, UX team, different Project teams and others). I especially use the “Exploration Bags” for team building and also for retrospectives.

At “Play 4 Agile 2013” every participant got one “Exploration Bag“:

LEGO Exploration Bag #p4a13

So I decided to do a session with those and get feedback on the LEGO retrospective I tried with teams already.

LSP is mostly about Story-Telling, creating metaphors, Constructionism, De-Constructionism. As a facilitator you try to enable “Flow” for the participants. In that state the participant is “fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia)

This is a set of activities that could be used in a LEGO retrospective:

  1. Warm-Up
  2. Build a feeling or mood that you experienced in the last iteration.
  3. Build your wish for the next iteration.

The session at “Play 4 Agile” was on Sunday morning, so we actually did a retrospective on the UnConference.


What normally happens is that after the third round (“Your wish for the next iteration.”) you have so many stories, themes or topics on the table. You can then simply start a discussion and create an action plan.

If you feel that the team members really liked the retrospective so far, you could finish with this activity: “Give one of the team members a gift and build this.”

I got really good feedback on the session. Thanks!
And I even got the “LEGO Rampensau Badge”. Yes!



Good Question!, Meeting Facilitation

Retrospective activity: Significance Story

Remind team members in a retrospective of the significance and meaningfulness of their jobs. After some bafflement they could realize again that their jobs are important and do create value.

This Monday I was inspired by the following tweet:

I tried to work with the answer (“Remind them why their jobs are important.”) in a retrospective activity straight ahead and thought it worked quite well.
Like a User Story Form (“As [role] I want [desite] so that [benefit].”) I asked each team member to complete the following empty columns by wiriting post-its:
My work as [role] has [this concrete significance] for [target group, user]. (Significance Story)

Retrospective activity: Significance Story

In the [target group, user]-column you will find several, different post-its. Ask in the next step what the expectations might be that those users have on them as a team. Let them again write their answers on post-its and stick those in a new, empty comlumn.

Finally let the team decide in a discussion which “Top 3” of the user’s expectations they want to measure up to preferentially.


2 3

Be surprised about the outcome.
In my case the team wanted to measure up to the exectation of being a team that creates value and that makes a difference. 🙂

Kanban, Meeting Facilitation

A Kanban Team Retrospective Activity


Although Kanban does not prescribe retrospectives (nor any other mandatory meeting) all our Kanban teams are doing retrospectives on a regular basis. As a facilitator of a retrospective you should try to create an awareness of why things went well or not so well and let the team discuss issues that hopefully lead to improvement (“Kaizen”). The following approach describes how to review finished tasks or User Stories of the last Kanban cadence and at the same time making the Spectral Analysis Chart (SAC) more vivid (especially if a team is at war with (Kanban) metrics anyway). 🙂

The team I’m working with at the moment agreed on a 2 weeks cadence: Every other Monday we meet for a retrospective to look for improvements. We collect all items from the “Done” column before the retrospective. I write the lead time (in days) on the ticket and order them according to their lead time ascending on a board (or the wall of the conference room).


Then visualize where the team’s average lead time is.


Concentrate in the retrospective on the tasks that are above/beyond the average:

– What are the reasons for the high lead time?
– What can we do to prevent that this will happened with future tasks? Can we do something about it?

Point out to the team members that the visualization on the board (or wall) is actually a SAC, only upside down. With this approach the team members create a better understanding of a SAC (as they connect it to “real” tasks) compared to just showing them an generated chart.


What do you think?

Kanban, Meeting Facilitation

Learning Playfully: Kanban Lead Time, Spectral Analysis Chart, Service Level Agreement

Some team members are at war with Kanban metrics (and probably other metrics): What are Lead and Cycle Time for? What does a Spectral Analysis Chart (SAC) show? Why should we care at all about a Service Level Agreement (SLA)? (Especially when there are so many dependencies with other teams.) You can always quote David Anderson or Wikipedia, but simply quoting won’t make sense to everyone. To better understand what Lead Time and a SAC are and how those are connected to a (desired) SLA, I tried a playful approach with one of our Kanban teams: “Show me your Data!”


– You need a couple of balloons, 2 decks of cards, some LEGO and index cards in different colors.
– Furthermore you need Post-Its or index cards and label those with “1-10 sec”, “11-20 sec”, “21-30 sec”, “31-40 sec”, “41-50 sec”, “51-60 sec” and “> 60 sec”. Stick those horizontally on a pin board.
– Write 9-12 tasks on index cards (Here some ideas for tasks: Mixed deck of index cards should be a color-sorted deck of index cards, inflate 3 balloons, sort out all red LEGO bricks, build a 3-level house of cards etc.)

How to Play:
You play in cadences.
The cadence starts when presenting the team 3 tasks that have to be done.
After that a stop watch starts and the team are working on the tasks.
When a task is finished, a team member sticks the task card in the appropriate column of the pin board in order to track how much time was spent on the task until it was finished.
When all tasks are done and the according task cards have been stuck to the pin board, the cadence end with a short retrospective: How did that work? What could you observe?

You play several cadences, depending on how many tasks you have prepared.

Before the last cadence you should start with a first debrief:
Lead time is… (If you need some good explanation check here.)
The SAC is exactly what can be seen on the pin board. (mirrored horizontically)

Now, supposing all those tasks were tasks of the team’s “Standard” service class, you can derive a SLA that results from empirical measurement of the tasks finished so far: 70% of all tasks will be done within 30 seconds (or whatever time the team needed for the tasks).
“So, let’s try to accomplish this SLA in the last cadence.”


The tasks in the last cadence should be a little harder: a 3-level house of Spade cards from an un-sorted deck of cards etc.
In this case the team can also discuss if it makes sense to split a task to finish the task within the SLA.

Why I think this game works:
It shows that metrics in Kanban measure the system and not the performance of the individual.
It explains very straight forward lead time and SAC and how to derive a SLA from those metrics.
If the tasks are not finished within the SLA, it is easy to discuss why that was the case and how the team could improve and deal with similiar tasks differently in the future.

I named the playful exercise “Show me your data!”.  David J. Anderson mentioned in his “Kanban Advanced Master Class” I attended in November 2012 that this is what he likes to ask Kanban teams he is working with: “Show me your data!”

Contact me if you want to try this game yourself and need more information. (I did 4 cadences the last time and thought it was quite enough. It took approx. 60 minutes.)

I wanted to get some feedback on “Show me your Data!”, so I held a session at “Play 4 Agile 2013“.
Thanks for the honest feedback from the participants. 🙂

Here it is:

  • Definitely a good exercise to explain how SAC works
  • Easy to understand exercise
  • When introducing exercise: Point out that you want to measure Lead Time (not Cycle Time).
  • When  introducing exercise: Point out that this exercise is not about WIP limit
  • Don’t emphasize on SLA. Rather ask the team to encourage some Kaizen:
    Why did the tasks above Average Lead Time took longer? How much longer did they took? How could we reduce the Lead Time of those tasks?
Kanban, Meeting Facilitation, Scrum

“Sexy Not-So-Sexy Tasks” Retrospective Activity

In one of the last retrospectives a team member complained about the “not very sexy” tasks the team had to do. Well, we all know that life is not all beer and skittles. Nevertheless I think, the team member was actually pointing out, that the “sexiness” of tasks can have impact on the general motivation of the team, of course. That’s why I was introducing the “sexy <> not-so-sexy” activity in the last retrospective. (As this idea originated in the team member’s comment I also call it “The Thomas S. Approach”. 🙂 )

sexy-not-so-sexy-tasks-agile-retrospectiveIn general, the team’s job is split in tasks on a support level (approx. 65%) and project tasks on a product development level (rest of their time). The team is working with a Kanban system and is using several Scrum ceremonies (regular retrospectives, review meetings, agile estimation for project tasks etc.).

The “sexy <> not-so-sexy” activity fits perfectly in between the check-in (“Setting the stage”) and “Gather Data” activities and is as easy as this:

1) Prepare a chart that shows a line between “sexy” and “not-so-sexy”.
2) Put all “done” tasks on the table and let the team stick them on the line accoring to the task’s “sexiness”.
3) Discuss (“Any suprises? Any patterns?”)

Why I think this acitivity works:

  • The team is reviewing their finished tasks while sticking it to the flipchart. (Reflection: “Cool, we have done quite a lot.”)
  • The team is re-evaluating the tasks. (Reflection: “Wow. That was a cool task.” or “I really hated that task.”)
  • The PO (Note: The team decided to have their retrospective with the PO.) realizes that different tasks can have different motivation.

Of course, the activity also shows the big gap between doing tasks that have value (“sexy”) and tasks that are simply stupid mechanics (“not-so-sexy”). Team members are aware of that. And it does have impact on the motivation if you are only doing “not-so-sexy” tasks.

As there will always be “not-so-sexy” tasks: Maybe there is a way to morph “not-so-sexy” tasks into “sexy” tasks? Any suggenstions?

The activity has been refinded after discussing it with one of the team members. He pointed out, that value is more “valuable” than sexiness. As a consequence I added the value dimension to the chart.

Sexy & Value-Added Matrix
Books, Good Question!, Meeting Facilitation, Scrum, Scrumban

Check-In Activity for Agile Retrospectives

Fortunately retrospectives are already a standard at our company now. Not only our developers teams, but also our sales team, our team assistents and as of late also our management (surprisingly, the last.. :)) have regular retrospectives. Because it has become standard to have retrospectives there is also the chance of falling into a dull routine, both for the team members and the facilitator (mostly myself). To counteract this dull routine we try to do different activities. I tried the following Check-In activity in the last weeks:

Esther Derby and Diana Larsen suggest in their book “Agile Retrospectives” as a Check-In activity to ask every participant “In one or two words: What are your hopes or wishes for this retrospective”. No post-its, no explanation, just one or two words. This always works great.

This question inspired me to ask participants an even more general question as a Check-In excercise: “Why are we doing retrospectives anyway?” I do this as a kind of fast brainstorming and jot everything down on a flipchart. It is surprising what the participants are coming up with. I heard everything from “I don’t know.” (Oops!) and “Because you told us to.” (Ooooooops!) to “Kaizen. Continuous Improvement.” (Thx.) and “We don’t want to do mistakes a second time.” (!!!)

It is also a good excercise to remind the participants of the principles of the agile manifest, one of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” (Dare to ask if everyone knows and understands the Agile Manifesto… and maybe be surprised.)

And, of course, it is a good excercise to jolt the participants from their retrospective routine.

BTW: I recognized only days ago that Esther Derby and Diana Larsen book “Agile Retrospectives: Making Good Teams Great” is legally available also as eBook! Buy it!