How to Facilitate a SAFe Big-Room Planning Meeting

IMAG6853I recently facilitated a two-day quarterly release-planning meeting for a customer. They were keen to use the Scaled Agile Framework-style “big-room” approach to the planning, so I attempted to support that as best I could. I’ll reserve commentary on SAFe itself (perhaps for a future post), but here I’ll describe some of the highlights and keys to the success of their meeting from my vantage point as facilitator.

Background

This customer is embarking on a mission-critical project that includes teams (business and delivery) in no fewer than six locations, spans nine hours in time zones and integrates at least four legacy systems. Many business and delivery team members had previously not even met each other in person. And most are relatively new to agile ways of planning and delivering.

The Challenge

The main deliverable in a SAFe big-room planning session is a Program Board, which is essentially a sprint-by-sprint breakout of the work for all of the teams in the Program Increment. It can depict dependencies and assumptions, but it’s basically the plan for the quarter (five two-week sprints or so). As I remarked to the group in my introduction, the plan we would create would be wrong because we’re trying to predict the future. But we would plan in such a way as to be adaptable as soon as we realized that the plan was wrong. The plan would include the What — what we’re mean to build and why we’re building it — as well as the How — the technical approaches, working agreements and roles of the people doing the work. We mainly followed the SAFe-recommended agenda, though as facilitator I did add a couple of things (which I outline below) and shaped the form of some of the SAFe stuff.

In addition to creating a plan, the group really needed to establish a shared understanding of the business context as well as of each other. With so many different people — including different native languages — it’s easy to distrust and make assumptions, so getting the group to bond as a unified team was one of my “subversive” goals.

Retrospecting

IMAG6886.jpg

Closing retrospective.

We retrospected at the end of each day. Facilitating a retrospective for nearly 50 people requires adapting the approach from that of a typical small delivery team. At the end of Day 1, I invited the group to split into mixed groups of up to eight people (following the rule of “Up to eight, collaborate”) and gave each a easel-sized sheet with categories of Stop, Start, Continue and Puzzles. Then I asked each group to have one person facilitate a discussion and decide on a couple of actions that they would like to suggest to the whole group. I then called the entire group together and had the “lay facilitators” come forward and present their ideas. We did a simple Roman vote across the room for each and amended the working agreements accordingly. As is usually the case in any retrospective, the best part was the conversation that ensued through sharing.

 

Keys to success

From my perspective, as well as from anecdotal and retrospective feedback, the following were keys to our success:

  • The right people (a.k.a. business and technical implementation people in the same room): When you’re dealing with distributed teams and
    IMAG6875

    RAID bingo.

    trying to deliver important business value, having the business people there to contextualize and simply interact with the technical implementation people is as valuable as the plan that they create. Far more important than any delivery methodology is a foundation of trust and understanding, and this group laid that foundation by having the true business stakeholders and users in the room, and not merely for a token pep talk talk at the beginning. Business people were talking about Minimal Viable Product releases and interacted with the delivery teams throughout the two days. And technical people gave a couple of product demos to the business, which yielded understanding and new ideas.

  • Strong facilitation and self-managing: The group never would have made the progress it did without disciplined commitment to its Working Agreements, which we outlined at the beginning. They were:
    • Check-in, Check-out protocol: I can’t say enough about how useful this is for a meeting of any size.
    • “Hands” rule: Since we often had lots of concurrent conversations happening (in team breakout planning, etc.), we were frequently loud. The old “hands” rule, in which one person holds up a hand and stops talking and thus creates a knock-on effect whereby everyone else follows suit allowed us to come to focus within 15 seconds of when I raised my hand.
    • Be on time: To facilitate this, I projected a giant countdown clock during breaks, and walked around holding with a “5 minutes remaining” card while people were in lively breakout groups.
    • “Yes, and…”: Borrowed from the improv world, this was a simple attitude that disposed us toward active listening and affirming what the other person was saying, so that we might build collaboratively rather than shut down conversation. Since most people were not previously familiar with the concept, we did the “Yes, and…” warmup as our icebreaker on Day 1.
  • Setting these agreements out upfront and “enforcing” them early allowed the group to self-manage and own the agreements, so that I had to really “intervene” only a handful of times. (And yes, we actually finished on time.)
  • Variety: No one likes sitting through back-to-back Powerpoints, struggling to stake awake; two full days of intense planning and thinking is difficult enough. So we mixed up the style of presentations and planning sessions using a variety of formats:
    • Games (or as Luke Hohmann would say, “collaborative frameworks”) for quick, collaborative discovery, like RAID Bingo
    • Lean Coffee for working through the Parking Lot/Car Park
    • Open Space for topics like deeper dives into the business, working agreements and tradeoff sliders
    • Warmup games for initiating conversation and creativity
  • Rearranging the space: We started with round tables of eight, but throughout each day we reconstructed the space, moving tables to create a circle of chairs, moving a couple of tables out of the room altogether and creating standing open spaces that encourages movement around the room. And of course, we had a designated “checkout table” in the back.
  • IMAG6833.jpg

    We used star stickers to indicate dependencies. These were the notecards that served as legends for reminding what color went with each team.

    Informative workspace: As is typically the case in release-planning meetings, we used loads of information radiators on the walls. This allowed us to share and persist the decisions and questions but also to create an engaged group, because we were able to all collaborate (a group of 50 physically can’t collaborate around a monitor or even a projection screen). By having the Program Board on one wall, the Story Map on another and Team Board all around, the room had no “front” but became a “theatre in the round,” which itself fostered collaboration and engagement.

  • Celebration and fun: Music, photo slideshow at the end, appreciations (gratitude board).

For next time

One bit of feedback was that we could’ve used one more day. I think that’s fair but will depend on how much face-to-face time a group has with each other (in this case, it’s warranted). And as focused and on-schedule as we were, one improvement I’d like to make for next time is to state the objective/outcome and people needed for each agenda card. Other feedback was to ensure enough space in the venue (we were cramped at times, so we removed a couple of tables on Day 2).

Summary

If you do it right, you get the stated “deliverable,” which is the plan. It might even be a pretty good plan (though all plans are guesses and therefore wrong!). But you also get something much longer-lasting and equally as valuable: the team building that fosters trust and communication, which in turn fosters collaboration and shared understanding. I can’t tell you how many times — and how deeply gratifying it was — to hear people exclaim, “Wow, I didn’t know that you did it that way in North America!” or “That really clarifies things for me!” Having the right people in the room, strong facilitation and engagement are they keys.


How’s my facilitating?

One of the hats I wear at Asynchrony is retrospective facilitator: I help teams improve themselves through self-reflection. But how do I know how I’m doing as a facilitator?

Improvement is predicated on feedback, so I like to quickly obtain feedback from the retrospective attendees so that I can adjust what I do for the next meeting. The format I’ve been using lately is based on the net promoter scoring system. At the end of the retro, I ask, “On a scale of one to five, five being very likely, how likely is it that you would recommend the retrospective experience you’ve just had to your colleagues? And if it’s less than five, how could I help make it a five?” Granted, the question is a bit hypothetical — even on my best days, I can’t imagine people going around the office saying “I wish you could’ve been at my retrospective today!” But I think it suffices to provide a simple framework for meaningful feedback.

IMAG4205

In the example above, the participants gave me a 60% Net Promoter Score (I treat fives as “promoters” and anything below a four as a “detractor”). That’s fine in a quantitative sense, as I can track my average over time, but what really interests me is the qualitative feedback, as it instructs me in actionable ways. For example:

  • One response was “it was kinda awkward at times due to hesitant participation.” This is a clue that I might want to design an activity for next time that creates better conversation or helps people feel more comfortable.
  • Another was “seems like we don’t have a lot to cover yet.” I didn’t do my job here: Even high-performing teams have things to improve, and the facilitator should help the team go beyond the surface. So this directs me to plan something more engaging and that helps the team mine their experiences a bit deeper.

I keep a running log of quantitative and qualitative feedback in a Google spreadsheet. This allows me to look for patterns over a broader time scale. And as I prepare for the next retrospective, I review the most recent feedback, which always gives me something to improve on. Just like I’m helping the teams to do.