Monthly Archives: March 2012

Facilitation Toolkit: Activities for Check In

15 Thursday Mar 2012

Posted by in Agile, Facilitation, Games, Links, Retrospectives, Scrum

≈ 6 Comments

Tags

This is the first of four posts covering facilitation games for the different phases of meetings: Check In, Opening, Exploring, Closing.

The Check In is the initial phase of a meeting, and to a large extent is independent of the content. The purpose of this section is to bring everyone’s focus into the room and establish the collaboration boundaries, so that right from the start we are all clear on what we expect of each other, and what we expect from the session.

For regular sessions like retrospectives with teams who know each other well, I jump straight to the Metaphor section below; for teams that are new to working together, or long facilitation sessions, I try to include all three steps as time allows.

Check In:

These activities signal the general level of attention, acknowledging outside distractions and bringing attention to the current objective.

  1. Fist of Five – Adapted to show how happy / informed / focused I’m feeling right now
  2. ESVP – How committed I am to being here (from Agile Retrospectives)
  3. Form a line – participants stand in a line from left (low) to right (high) in response to a question such as ‘How I rank my level of knowledge’
  4. WIIFM – have participants write their “What’s In It For Me” (What I want to get out of this session) on a stickynote and stick it up on a designated wall space. If time allows, have them discuss this in small groups first. Revisit at the end of the session as part of closing. Defines personal objectives, generates ideas for others, and also gives the facilitator some perspective on the group’s expectations.

Create Safety:

These activities are designed to maximize collaboration. Developing personal connections between participants and setting the boundaries of the meeting help to establish initial trust.

  • Introduction Card – Pair activity: create a card for your pair stating their Name; Role; Interesting Fact; and Superhero Quality, then introduce them to the group. Fun introduction technique, creates bonds & generates laughter (from our Coaching Dojo)
  • Working Agreements – Agreement on how we’ll handle distractions, conflict, tangents etc. either long term as a team or for the current meeting (from Agile Retrospectives)
  • How can we make this (retrospective / session) fail? Round robin format – this is a fun way to surface fears and create awareness of unsupportive activities and attitudes, and agreement on how to avoid them or handle them if they come up.
  • Focus On / Focus Off – Another way to bring awareness to collaborative vs obstructive behaviours (from Agile Retrospectives)
  • Hope for the meeting / sprint etc. – Creates a shared understanding of individual objectives (from Agile Retrospectives)

Check In Metaphor:

Once the conditions of safety have been established, a quick ‘Turn the Head’ activity suffices as a Check In, providing a meaningful transition to the Opening section of the meeting.

It’s ‘disruptive’ as it challenges our thinking by bypassing the jargon we use on a daily basis, to create new associations and insights. Metaphor check-ins can also give a heads-up on underlying themes or tensions, but are quick enough to simply highlight issues without pre-empting a tangential conversation.
These ideas appear in both Gamestorming and Agile Retrospectives.

  • Describe (the sprint / release / team etc.) as a:
    • Fruit, food, drink – rich associations with wide applicability; can surface emotions
    • Car, mode of transport – drive & motivation in the team
    • Colour, sound, other senses – wide applicability; can tend towards the abstract; useful for volatile situations
  • Drawing:

While there is always someone in the room who “can’t draw to save their lives,” I’ve never seen this exercise produce trivial insight. Both metaphor and drawing can create new neural networks that help to situate each participant’s experience; drawing goes further by using a different form of language and connecting different spheres of brain activity. The debrief experience tends to be rich, and contributes to building trust within the group.

… and then sometimes I just ask for any 2 or 3 words, or a highlight and lowlight, that start the discussion. This is particularly useful when I don’t know the group, when emotions are running high, or there have been a variety new experiences.

Most of these activities come from books, blogs or training sessions I’ve been part of; some I’ve created to meet specific needs. Where I can find attributions they are noted; if you see any I’ve missed, or know of links I haven’t found, please let me know in the comments below.

Facilitation Toolkit: Working with Games

14 Wednesday Mar 2012

Posted by in Agile, Facilitation, Games, Retrospectives, Scrum

≈ 4 Comments

Tags

I’m often asked where to find facilitation games and formats for agile teams. Fortunately there’s an increasing amount of information on the web, a number excellent books on the topic and some great training courses available – and since it’s an ever-expanding world, the more you look the more you’ll find.

Over time I’ve assembled a list of favourite collaboration games covering a wide variety of applications, which I’d like to share over the next few blogs. To make sense of them, it helps to understand a little bit about the activities we call Games.

What is a Facilitation Game?

The idea of games being inappropriate or irrelevant in a business context is fast losing ground as we begin to understand the value of collaborative and innovative approaches to problem solving.

Games are designed, interactive experiences in a variety of formats, generally following an ‘Opening – Exploring – Closing’ structure. I distinguish between ‘empirical experience’ games and ‘collaborative’ games, as follows:

  • Empirical experience games are safe-to-fail learning activities that simulate real-world scenarios from which we gain deep experiential knowledge quickly, as opposed to theoretical knowledge. They have a powerful learning value which helps us act more consciously when we’re in similar situations in the real world – but many organizations still distrust their un-businesslike characteristics.
  • Collaborative activities are called ‘games’ because they follow the game format of open – explore – close; the activities are interactive, with ‘set moves’ directed towards an overall goal, and an outcome which is determined as a result of the collaboration.

Collaborative games tend to be easier to adopt in meeting agenda as they readily support business objectives, and while the level of collaboration may feel unusual at first, the quality of the interaction compared with traditional meetings quickly establishes their value.

This is where the focus of the next few posts will be.

What’s in an agenda?

We can apply the gaming ‘open – explore – close’ structure to designing the facilitation agenda as well. There are different kinds of activities for each part of the meeting, and following this format creates a balanced pace through the session to keep participants focused and engaged.

For retrospectives I generally combine this structure with activities focusing on past, present and future, as described by Esther Derby and Diana Larson in Agile Retrospectives, and a small addition of ‘disruption’ I encountered in Loop Organisational Consulting’s Team Leadership Skills course. This gives us:

Check In > Turn The Head > Gather Data > Insights > Goals & Actions > Close
which is roughly:
Open > Refocus > Past > Present > Future > Close

‘Turn The Head’ highlights the value of the disruptive element to adjust our viewpoint so that we can see our world through different lenses.

I also use this overall structure for other sessions, with a greater emphasis on the specific area of focus, as well as icebreakers or empirical experience games as appropriate.

Sharing the Agenda

I’ve learnt to start meetings with a discussion of the agenda and how long we’ll spend on each section, and keep this visible for the duration of the meeting. Initially I resisted the idea, with worries like “what if it goes wrong; what if people don’t like it, and I want to change direction?” but I’ve been amazed at how much collaboration improves when participants can see the overall context of each activity … and I’ve also learnt that changing direction with the full awareness of the group is far more effective than rigidly holding onto the plan or appearing unprepared when circumstances change.

Developing a wide and deep toolkit gives us the flexibility we need as facilitators to respond to our changing circumstances. Each of us builds up a unique set that works for our environment, and which also evolves with time.

In the next few blogs I’ll be sharing some of the tools I’ve enjoyed using for each of the major sections of a facilitation:

* Links will become active as the posts are published.

What is Agile Facilitation?

05 Monday Mar 2012

Posted by in Agile, Facilitation, Retrospectives, Scrum

≈ 4 Comments

One of the more distinctive differences between agile software development and its traditional counterparts is the wide-spread adoption of group facilitation techniques by agile practitioners.

This is largely due to the high degree of collaboration demanded by agile methods: we have to learn effective ways of sharing information and making decisions together – so much so that it’s become one of the Scrum Master’s major responsibilities.

I see facilitation as a foundation support for self-organization, and critical to new management practices: the fundamental understanding that an informed collaborative approach to problem solving involving those closest to the work will consistently yield better results than a plan designed by a single expert.

So what is facilitation?
As a field, facilitation is hard to define. Wikipedia and Google give us a view of the wide range of contexts in which the term facilitation is used, from business to neuroscience.

These give us a good overview, but I worry about definitions that tell us facilitation is ‘making things easier’ (from the root ‘facile’). Because while facilitation is a significant aid to collaboration, as experience tells us, collaboration is not easy. Good facilitation provides ways to address this and make it more comfortable in the long run, but it’s neither a magical panacea for problem resolution nor a superficial fix we can use to avoid conflict.

To clarify my understanding of the field, this is my take on facilitation (I won’t claim it’s the most elegantly worded):

Facilitation is the “art” (an informed blend of techniques and insight) of aiding groups to collaboratively interpret their (project) context and identify the most valuable path forward.

From a continuous improvement perspective, we know that having clear and attainable goals set and agreed on by those doing the work is a fundamental factor in both motivation and team success. Coupled with the short cycles of Scrum, this provides an excellent mechanism for teams to improve incrementally while responding to changing conditions.

But we also know from complexity theory that there are situations when it’s just not possible to see up front what the desired outcome might be, and setting predefined goals or actions can be meaningless, or even damaging if they lead us in the wrong direction. In situations where work emerges as we go along, a facilitator needs to be able to help the team clarify the boundaries in which exploration can take place, and understand how to navigate these waters.

In either circumstance, the facilitator ensures that teams reflect regularly on the process, either to clarify whether the activities undertaken are leading them to the intended outcome; or to ensure that they are conscious of the steps they’re taking, the results generated and the kinds of patterns emerging – and what these indicate about next steps (Cynefin‘s Probe – Sense – Respond model). The detail of what and how to proceed is a product of the facilitation itself, not a predetermined formula.

From this perspective, agile facilitation is about reaching a new level of understanding; surfacing valuable insight that will get the group to their next stage – whether it’s a vision, the next sprint, or a new team dynamic.

Outside of continuous improvement, the Scrum Master facilitation functions include planning well for meetings, using time-boxes effectively, and ensuring good communication flow both within the team and across organizational boundaries. At a process level, it’s ensuring that coming work is appropriately groomed and that everyone is aware of constraints so that the right expectations are set.

Here the facilitator function is making sure that the time utilized and the effort expended are appropriate and valuable, and that there is as little as possible waste in both meetings and normal day-to-day activities.

And this is part of the ‘art’ of facilitation: how do we know what is wasteful and what beneficial? What level of noise is required for us to have sufficiently investigated all areas?

In different contexts, discussing a tangent or exploring an alternate technology could be beneficial, harmful, or irrelevant – but if it’s important enough to come up, we need to ensure that we explore sufficiently for the first two possibilities, and avoid the last. Again, this call must be guided by group input. Facilitation involves making sure everyone involved with a decision has a voice, is clear on both the constraints and possibilities, and is able to proceed in an informed manner.

It’s well noted that the facilitator does not provide answers, and as a rule does not contribute to the content. What they create is the most conducive environment for each individual to contribute their knowledge and clarify their concerns, such that the group is to be able to choose the best route for their situation, as a self-organized team responding to business needs.

And do to this well, we need a wide and deep ‘toolbox’ of techniques, from idea sharing to consensus activities, which allow us to respond in a contextually relevant way to the range of challenges with which software development so regularly furnishes its practitioners.