Facilitating a group of people towards a shared outcome is a valuable skill in any team. For a few years, Scrum Masters, facilitators, consultants and others have gradually been discovering an amazing resource that can help.
Liberating Structures are a set of facilitation recipes that have inclusivity at their heart. They are an alternative to traditional structures that can leave people disengaged or allow a minority to dominate.
There are thirty-three structures in total, each appropriate for different group sizes, contexts, and outcomes. Here is one example that demonstrates the approach
Here’s how the facilitator used Liberating Structures to make this event better
Step 1: Understand the event characteristics and outcomes:
Typically 5 – 10 people in an established team of cross-functional engineering and product specialists.
Create a plan, forecast, and goal for the development of product features over a fixed time, typically 2-weeks.
Step 2: identify anti-patterns of traditional / current structures
- Lack of a compelling sprint goal or objective
- Running through long lists of tickets creating disengagement
- One person “driving” the ticketing system and doing all the talking, excluding others
- Meeting format favouring more vocal or confident attendees
- In-depth discussions arising between a small section of the group
Step 3: Select Liberating Structures that can overcome these limitations:
Creating a compelling goal: Troika consulting
- The product owner briefly explains what they are hoping to get done by the end of the sprint
- They then turn around (or switch off their camera) and listen
- The rest of the team discusses what the goal of the sprint should be
- Once a goal has been created, the PO turns back around and gives feedback to finalise the sprint goal
Why does this work?
>It creates space for the team to step into, once the product owner has taken themself out of the conversation. The team is likely to connect more with the goal that they created.
Avoiding disengagement and low participation: 1-2-4-all
- Each backlog item is selected and briefly re-introduced by the PO
- 1 minute: Developers individually identify sub-tasks they think will be needed
- 2 minutes: Developers pair up and de-duplicate
- 4 minutes: Pairs form into fours and de-duplicate, adding more subtasks if they emerge (be flexible if there are odd numbers…)
- All: Final de-duplicate and confirmation
- Select the next item from the backlog, and repeat
Why does this work?
The structure deliberately levels the playing field for participants with differing levels of confidence, knowledge, experience, and assertiveness. Everyone has the opportunity to create ideas, and to share with small groups. This increases the chances that edge-case tasks will be identified, and also ensures that every participant plays an active part in the event at least every 8-10 minutes.