This retrospective design makes it simple to facilitate, enjoyable for participants, and opens people's eyes to the cause-effect relationship of the bigger system (beyond the team).
While attending an open space conference in St. Louis a few years back, I convened a session called “Visualize All the Things!” In the session, participants were invited to make use of a giant wall next to the marketplace -- and covered in whiteboard paint -- to draw, illustrate, and reveal all the ways we can visualize information. Each person took a turn to introduce the visualization technique, explain the purpose and utility, and answer questions.
Among the many interesting contributions was a retrospective format contributed by Derek Wade. As he explained his design, how it incorporates elements of “gather data” and “generate insights” seamlessly, and tips for facilitating it, the session participants were quick to snap pictures. One person enthusiastically exclaimed, “Oh, I am SO using that at my next retrospective!”
Since learning the technique, Derek’s retrospective format has been my “go-to” method for introducing to new facilitators, teams, and people who have never experienced a truly effective inspect and adapt activity. The design makes it simple to facilitate, enjoyable for participants, and opens people's eyes to the cause-effect relationship of the bigger system (beyond the team).
Have I fired up your curiosity? Great! Here’s how it works, including insights and facilitation tips from Derek himself!
When the team is ready to begin (preferably after an exercise to the set the stage or focus attention), ask the participants to write down “notable events” without introducing judgement.
When people have finished writing (or, if using a timebox, time has expired), ask everyone to place their stickies on the wall. Encourage the group to observe and read others’ notes, but without comment.
On the wall, create a vertical (y) axis. At the bottom, place the label, “went well.” At the top, the label, “not so well.” Instruct the participants to place their sticky notes along the vertical (y) axis according to the labels.
e.g., for something that went really well, a team member might place it all the way at the bottom of the axis. For something that was a minor inconvenience, she might place it more in the middle, or leaning towards the top, of the axis.
Once the team has an understanding of the content on the wall, add a second dimension to the picture. At the bottom of the vertical (y) axis, create a horizontal (x) axis. On the left side of the axis, place the label “can control.” At the right end of the axis, place the label “can’t control.”
Introduce the new dimension to the team and instructions: for our experiences together this sprint, some things may be fully in our control. For others, we may feel helpless. Without changing the vertical position, move the sticky along the horizontal (x) axis to indicate whether the team believes they can control, or cannot control, the item.
When the team is satisfied, create a new layer for the team in the form of a 2x2 grid. Using your available materials, divide the picture into equal horizontal and vertical parts. Label the 2x2 grid:
Facilitate the new picture with the team and invite them to discuss further.
At this point, the team has reached a place where they have collected important data about their experience working together, discussed the impacts, and generated insights about their work environment. Here, the team is in a good place to begin exploring what they want to do. Perhaps they want to share ideas for fixing a problem in their control? Maybe they feel strongly for escalating and influencing an issue beyond their control?
You may find it’s simple and intuitive to have teams dot vote or, if a decider protocol exists, simply ask the team to act on what they have the most energy for. Once a team has identified what they want to experiment with or adapt, a force-field analysis is a great way to elicit actions.
And sometimes, this method resonates with people so well, ideas for improvement are simply evoked naturally in the discussion. For more ideas to assist people with action after using this technique, including helpful tips from Derek, see the tips for facilitator’s below!
If you’d like a little more structure before you try this technique, here’s some pointers.
As a retrospective activity for people, some base conditions must be present to make the experience both useful and human friendly. A great design will be ineffective without safety and adequate time (free from pressure).
You should plan for approximately 90 minutes to gather data, generate insights, and determine what to do. It’s possible to do this faster (the first instance of this technique ever running was completed in 20 minutes, but that’s a rare case. Make time.)
You’ll need a wall, a means to create a grid (a whiteboard or painter’s tape work great), sticky notes, sharpie pens, anything to help people feel happy and comfortable (food, drink, fidget toys, etc.)
It’s generally a wise idea to ask people to silently brainstorm while writing, reducing the risk of dominating voices. The prompt you give people will influence what they write, so they will appreciate you giving some definition of the boundaries within which you’d like people to reflect.
For example, if a team recently finished working together over two weeks, advise them the exercise spans only that two week time horizon. In addition, unless there is a specific event or topic the team intends to address, it’s helpful to give people an open-ended place to brainstorm: “please write down any event that sticks out in your mind, for whatever reason -- positive, negative, surprising, perplexing -- if it was significant, jot it down.”
It’s easy to accidentally flip the vertical (y) axis, with “good” at the top and “poor” at the bottom. While it might feel unintuitive at the first step, there’s a good reason for it which comes out in the “Digital” phase.
During the sorting activity, facilitate the emerging picture with the team and invite them to discuss what they see. For those new to facilitation, you might consider open-ended questions like:
Inside/Outside the Team
Here is where the ‘unintuitive’ arrangement of the graph axes can help the team see themselves as part of a larger system: Placing “good” at the bottom visually emphasizes that “keep doing” is CORE to the team, at the origin of the graph, and perhaps not something we need to push on yet. Facilitators might even consider drawing concentric quarter-circles out from the origin, illustrating to the team how we can mature by “moving outward.”
“I ran this format multiple times with the team where I first developed it. What was interesting is later on they noticed that improvement meant there was 'gravity' to the graph origin: ‘You know, those bad things that used to be out of our control are still showing up here, but they're down here (points to lower left quadrant) because they've gotten better, and more within our control.’ A continually improving organization continually in toward the graph origin.” -- Derek
This is where you convert the new system-level visibility that the team now has into action. Unless you have a good reason to limit the team’s attention to a particular quadrant, using some form of decider to focus their actions is key.
Important insight from Derek:
The two biggest challenges I find in keeping retrospectives useful are usually not the retrospective itself, but in what comes after:
For the first, I use dot-voting with sharpies to select the top 1-3 "Fix" / "Escalate" issues they wish to tackle/want tackled for them, and then generate one action they wish to take/be done.
For the second, we take the issues we selected, and they go on a separate board where we move them through the Deming Cycle. (PDCA) At the START of the next retro, we revisit any items in the "Check/Adjust" phase. Often they get celebrated as yielding improvement... but sometimes they show up again in the next retro as a new item ("action to fix the foobar problem didn't help much")
After all, improvement should be continuous.
Zach Bonaker is an agile coach based in San Diego, California, USA and has more than 10 years of experience assisting software organizations with improving working conditions and results. Acting as a "benevolent trouble-maker," Zach builds relationships to help transform people, systems, and structures towards safer and collaborative ways of delivering high quality software. Zach is an international conference speaker, frequent podcast guest, and contributor to the global agile community. When he isn’t thinking about next-generation agile ideas, Zach can be found enjoying the sunny California weather and connecting with people all over the world. For more content from Zach, please see:
Derek W. Wade founded Kumido Adaptive Strategies, an organizational performance consultancy, to help teams innovate together. As a “wide-mind coach,” his cognitive approach to Lean/Agile models has improved creative efforts across a broad range of industries. Derek is a recognized speaker and educator, appearing at forums including Lean-Kanban France, Science of Team Science (SciTS), the Agile Alliance, and Agile Games New England. Derek has served on the Board of Directors for the Agile Leadership Network, is an Accredited Kanban Trainer, and holds FAA Commercial Pilot/Flight Instructor certifications. Derek tweets at @derekwwade, blogs at derekwwade.net, and does neither as much as he should because he prefers working with people.
What can you actually do to make effective retro a reality? The good news is, it’s not as difficult as you might think. We’ve broken it down into 5 elements to make it as easy as possible to massively improve your sprint retrospectives.
Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Often that dynamic plays out in metrics and misguided attempts at fostering engineer productivity, usually by measuring the wrong things and offering the wrong incentives. Fortunately, there are better ways to use metrics to genuinely empower engineers to accomplish more.