Facilitation is rarely discussed outside the context of having meetings, but there are a lot of kinds of facilitation. Teaching is facilitating learning. Project management is facilitating work.
I’m a trained Scrum Master, which is another name for a facilitator within the Agile working framework of Scrum. (Scrum 101: scrum teams work together in a defined span of time called a sprint to complete a discrete and deliverable part of a bigger project. Then they review their working methods in an event called a Retrospective, adjust their process, and then in their next Sprint Planning meeting, they break off another chunk of work to be completed in the next sprint. The fundamental difference between traditional project management and the Agile/Scrum framework is the frequency of review and iteration on smaller, discrete portions of a project vs a focus on delivering an entire complete project all at once).
Scrum Master is an interesting role, rooted in removing obstacles from the working team, but also working to provide a supportive environment in which the team can work. One of my favorite scrum tools is the daily standup, a meeting not owned by any one person but by the team, in which everybody is asked three questions:
- What did you do since we last met?
- What will you do before we meet next?
- What roadblocks are in your way?
In a true scrum setup, the Scrum Master is the sweeper: removing the roadblocks and making the path smooth!
But that framework is really useful in non-scrum settings, too. I’ve adopted it for use in most projects I’ve worked on, regardless of team type. It makes the most basic and useful meeting agenda format there ever was!
The part of the sprint where the team pauses and reflects is my favorite part of scrum, because the best work happens when you look at your own process and methods. What disrupts your ability to get work done? What disrupts the team’s trust in each other? It’s so important to stop and look honestly and openly at how the team is working together. It requires the team to be vulnerable with each other, to be able to receive and give criticism in a safe and productive way, and to think honestly about how the team is working.
A retrospective will not be productive if you haven’t made space for people to be vulnerable, and there are a lot of tools and techniques you can use to help create that environment. Here’s an example of a retrospective agenda I’ve used:
- Reminder of the goals/objectives of the retrospective
All team members reflect on the past sprint and make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
“How did the sprint go for you?” in only two words. Each person writes their two words on the board.
- Happiness Histogram (see below for examples)
a) Review the burndown chart and sprint calendar to remember what happened during the sprint.
b) Draw a graph with time on the x and happiness on the y axis, (Happy is above the axis, Sad is below, and neutral is the X axis). Label significant events e.g. planning, sprint review, and backlog reviews, important meetings, environment failures, branch merges etc. on the x axis.
c) Everyone draws a line representing how they felt throughout the sprint.
- Gather data and generate insight
Prepare sheets of paper for each team member each with one question:
In this sprint, what things happened that were unusual?
In this sprint, what things did we do well?
In this sprint, what did we do that we should avoid doing in the future?
Distribute the sheets. Each person writes something, then passes the sheet to their left, then writes something on the next sheet, in response to what has previously been written. Give 3-5 minutes for each round, then instruct the team to pass the paper to their left. Stop when participants have the sheet they started with.
- Decide what to do
Ask people to read their sheets and write the main points on post-its, on the board. Ask people to read the post-its aloud. Distribute 5 dots per person. Each person votes by post-it (however they like). The goal is to select one or two things to actively work on in the next sprint.
- Close out (Return On Time Invested)
(See Facilitation 105 for more info on how to use the ROTI tool.)
I love happiness charts. When we use these, we decide up front that we’ll use them, so we can define our rating system (-3 to 3, for instance, where 0 is neutral) and set up a table to track ratings. Every day during our morning standup meeting, each person gives a number ranking to how they felt about the previous day, the scrum master writes it down, and we map it out as we go (in a spreadsheet, or on a whiteboard, or on paper).
Here are some examples. You can see really readily when the team is in total alignment. Note the huge tank from everyone on the team at the same time, early in the sprint here:
It also reveals when the team is way out of alignment. Look how everybody’s lines are all over the place in this sprint:
The real value of happiness charts though, is going back through and identifying WHY folks felt great or terrible. Folks often feel more at ease talking about emotion when it’s rooted in “data” (as much as a gut-take feeling on a made-up scale is data) so it can be a lot easier to identify from a graph, rather than from conversation alone, what the team is struggling with, and thus what you as the facilitator or scrum master may need to focus on. And it also provides a framework for people to point jubilantly at a peak and say what happened that made things go well. I’ve gotten to hear some really lovely and supportive commentary from the team about each other. In one of my favorite retrospectives, we learned that the highest points on the happiness chart were when the team was really struggling, but felt supported by each other and able to work through the struggle.