I 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.
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 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.
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
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.
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).
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.
- Implement in the Learning Team the good practices you hear about in Agile Overview, then
- Implement in your future customer-facing team the good practices you experience in the Learning Team.
For new hires and veteran AsynchronitesWho need to learn the Asynchrony delivery “way,” brush up on skills or learn new onesThe Learning Team is an internal delivery teamThat provides a safe place to learn proven practices and experiment with new onesUnlike being thrown straight into a team without knowing what great delivery practices look likeThe Learning Team is an exemplar team where people can learn healthy practices that they can take to other teams.
I’ve recently attended a couple of thought-expanding conferences and met many inspiring people (including a few back at the Asynchrony St. Louis office), so I’m sharing some of the recommendations that I’ve picked up from keynotes, sessions, hallway chats and pub discussions. Here are a few things that people have been talking about, some of which have been around for a few years:
- Antifragile (book), ALEConf
- Dixit (game), ALEConf
- Hanabi (game), ALEConf
- Thinkertoys, (book), ALEConf
- Indxd.ink (tool), Alison Hawke, Asynchrony
- IDEO Deep Dive (video), Rich Sheridan, Lean Agile Scotland
- Wardley (value chain) Mapping (technique), Will Evans, Lean Agile Scotland
- Barry-Wehmiller (organization), Rich Sheridan, Lean Agile Scotland
- Zara, My Agile Role Model (video), Clarke Ching, Lean Agile Scotland
- Amy Cuddy TED talk on body language (video), Chris Matts, Lean Agile Scotland
- Temple Grandin (movie), Sal Freudenberg, Lean Agile Scotland
- Crucial Conversations (book), Clarke Ching, Lean Agile Scotland
- Made to Stick (book), Clarke Ching, Lean Agile Scotland
- The Goal (book), Clarke Ching, Lean Agile Scotland
- The Phoenix Project (book), Clarke Ching, Lean Agile Scotland
- Strategy Deployment Canvas (technique), Matt Barcomb and Cat Swetel, Lean Agile Scotland
- Pawel Brodzinski’s flow-based road mapping (technique), via Matt Barcomb, Lean Agile Scotland
- Featureban game (activity), Mike Burrows
- Divide the group into multiple small teams of 3-5 people.
- Have each team draw on a wall/large-poster sheet a 4×4 grid* with column headings of R, A, I and D.
- Instruct the teams to write risks, assumptions, issues and dependencies on post-it notes and place them in the appropriate columns as fast as possible. The goal is to be the first team to have three items in any column or four in any row. The first team to do so should shout “Bingo!”
- When a team shouts Bingo, tell all teams to pause. Invite the winning team to announce and briefly describe each of their items.
- Resume play! Have the teams keep their post-it notes on the boards and continue to try to get a(nother) full column or row.
- The next team to shout Bingo must have all unique items (they cannot have the same items that the first winning team used).
- Repeat until the teams have covered most of their boards (usually by the third “Bingo”). Then do the final Bingo “coverall” — first team to cover all squares wins.
After you’ve generated many unique project concerns, unify all teams’ contributions into one board. At this point, you can discuss them in more depth or simply defer the discussion and mitigation strategy until later (but hopefully not too much later!).
Scrum gave us the Three Questions to help structure discussion at daily standup. These questions provide some idea of micro-goal setting and accountability for each team member and can be a healthy practice:
- What have you completed since the last meeting?
- What do you plan to complete by the next meeting?
- What is getting in your way?
For teams who are increasingly focusing on optimizing flow or teams who have simply fallen into a pattern of rote repetition and are in need of a fresh approach, I offer what you might call “the new three questions,” inspired by Mike Burrows in his book Kanban from the Inside:
- How can we improve flow today?
- What is blocked and why?
- Where are bottlenecks forming?
A colleague observed that those questions sound like a mini retrospective, which is not a bad analogy insofar as they are about improvement, though perhaps not as backward facing; they focus on the present and near-future reality. They’re about making a plan to improve flow, with the scope being merely a day. I like the questions because they orient the team toward the work, rather than the worker. For teams that already follow the practice of making work visible, the new three questions are a natural complement to “walking the wall.” Furthermore, the answers to these questions over time can inform the conversation at operations review and risk review, helping the team analyze their work-in-progress limits and blocker clusters.
Like any practice, without attention to the “why” and context, they can lead to to mindless repetition. But if flow is important to you — and it should be — “the new three questions” can help you improve it with a simple twist on an old reliable pattern.
Daniel Vacanti’s new book, Actionable Agile Metrics for Predictability, is a welcome addition to the growing canon of thoughtful, experience-based writing on how to improve service delivery. It joins David Anderson’s (Kanban: Successful Evolutionary Change for Your Technology Business) and Mike Burrows’s (Kanban from the Inside) books in my list of must-reads on the kanban method, complementing those works with deeper insight into how to use metrics to improve flow.
Daniel’s message about orienting metrics to promote predictable delivery and flow — which he defines as “the movement and delivery of customer value through a process” — is primarily grounded in his experience helping Siemens HS. He includes the case study (which has been published previously and is valuable reading in itself) at the end of the book, so he keeps the rest of the book free from too many customer references, though he’s drawing on the pragmatic experience.
As someone who for several years has been helping teams and organizations improve using the metrics Daniel talks about, I learned a tremendous amount. One of the reasons is that Daniel is particularly keen to clarify language, which I appreciate not only as a former English major (nor as a pedant!), but because it helps us carefully communicate these ideas to teams and management, some of whom may be using these metrics in suboptimal ways or, worse, perverting them so as to give them a bad name and undermine their value. Some examples: The nuanced difference between control charts and scatterplots and clear definitions on Little’s Law (and violations thereof), especially as related to projections and cumulative flow diagrams. I certainly gained a lot of new ideas, and Daniel’s explanations are so thorough that I suspect even novice coaches, managers, team leaders and team members won’t be overwhelmed.
As for weaknesses, I felt that the chapter on the Monte Carlo method lacked the same kind of depth as the other chapters. And I came away wishing that Daniel had included some diagrams showing projections using percentiles from scatterplot data. But those are minor plaints for a book that constantly had me jotting notes in my “things to try” list.
Overall, I loved how Daniel pulled together (no pun intended), for the purpose of flow, several metrics and tools that have often been independently implemented and used and whose purpose— in my experience — was not completely understood. The book unifies these and helps the reader see the bigger picture of why to use them in a way I had not seen before. If you’re interested in putting concepts and tools like Little’s Law, cumulative flow diagrams, delivery-time scatterplots and pull policies into action, this book is for you.
- The book has a very helpful and clarifying discussion of classes of service, namely the difference between using CoS to commit to work (useful) and using it to prioritize committed work (hazardous for predictability).
- It also had a particularly strong treatment of cumulative flow diagrams.
- Daniel does a lot of myth debunking, which I appreciate. Examples: work items need to be of the same size, kanban doesn’t have commitments.
- The tone is firm and confident — you definitely know where Daniel stands on any issue — without being strident.
I’ve been helping a team at Asynchrony improve using blocker clustering, a technique popularized by Klaus Leopold and Troy Magennis (presentation, blog post) that leverages a kanban system to identify and quantify the things that block work from flowing. It’s premised on the idea that blockers are not isolated events but have systematic causes, and that by clustering them by cause (and quantifying their cost), we can improve our work and make delivery more predictable.
The team recently concluded a four-week period in which they collected blocker data. At the outset of the experiment, here’s what I asked a couple of the team leaders to do:
- Talk with your teammates about the experiment
- Define “block” for your team
- Minimally instrument your kanban system to gather data, including the block reason and duration
The first two were relatively simple: The team was up for it, and they defined “blocker” as anything that prevented someone from doing work if he had wanted to. “Instrumenting the system” wasn’t as easy as it could’ve been, because the team uses a poorly implemented Jira instance, so they went outside the system and used post-it notes on a physical wall. They then kept a spreadsheet with additional data (duration, reason) to tie the blockers back to their Jira cards.
Over the next four weeks, the team collected 19 blockers, placing each post-it note on the wall in either an “internal” (caused by them) or “external” (caused by something outside the team, including customer and dependent systems) column. We then gathered in a conference room to convene a blocker-analysis session to:
- further cluster the blockers into more discrete categories
- calculate how many days of delay (the enemy of flow!) the blockers caused
- root-cause the internal categories
- find out where to focus improvement efforts
The analysis session was eye-opening. We started with the two main columns (internal, external) and as we quickly discussed each blocker, sub-categories, such as “dependency” and “waiting on info” emerged. Within minutes, we were able to see — and quantify the delay cost — of the team’s most egregious blockers.
internal blockers caused 20 days worth of delay
external blockers caused 147 days worth of delay
- the biggest blocker cluster accounted for 86 days of delay
That biggest blocker cluster now allows the team to have a conversation with the customer that goes something like this: “Over a four-week period, we had three blockers in this area. If this continues, that means you have a 75% chance each week of creating a blocker that costs you an average of 29 days. Is this acceptable to you?”
Ultimately, it may indeed be acceptable. But the customer is now aware of the approximate cost of problems and can manage risk in an informed way.
For the internal blockers, we conducted a root-cause analysis (using fishbone technique, though I’ll admit my “fish” leaves something to be desired!). So the team can go forward to address both external blockers (through a conversation with the customer) and the internal blockers (through their decisions).
Other lessons learned:
- Some blockers turned out to be simply time spent chasing information about backlog items rather than true blockers of committed work, so the team added “… for committed work” to their blocker definition. (It’s important to understand your commitment point.)
- Depending on how you want to address blockers, you might choose to sort them differently. For example, the team considered sorting its external blockers not by source but by which customer contact was responsible.