Beats in the Dojo Loop: Share (3 of 4)
This is part three of a series on how iterations work in a dojo challenge. See Part 1: Plan, Part 2: Do, Part 3: Share (this post), and Part 4: Reflect for the whole story.
After planning our work, spending most of the time doing our work – low and slow, metacognitively focused on how we're approaching problems in a new way – it's time to share! And we share more than just the output of our hyper-sprint, we share our learnings and direction.
Sharing is a short session, usually 30 minutes, where the dojo challenge team gathers their stakeholders – customers, financiers, leadership (technical, product, business) – to share what they've done, what they've learned, and where they are headed. If this sounds like a Scrum demo, then you're partly right. Partly.
The team will walk through "potentially shippable" or, better, already delivered functionality of their software, much as in a classic agile demo. Leaving it at this tends to create an atmosphere of "feature theater," at worst reinforcing output/scope-driven/deadline culture.
The chicken to delivery's egg is some form of light storytelling around what product theories and knowledge shook out from the current hyper-sprint's discovery activities. The best stories embed insights and artifacts in a lucid narrative. These facts may include customer journeys, research, user test results, interview results, and prototypes of various fidelity.
Storytelling is a part of the design thinking process. It helps align stakeholders to the vision held by the product team and primes more productive and advanced communication. Neil Stevenson, Executive Portfolio Director at IDEO, describes an occasion where storytelling helped collaborators and stakeholders imagine an experience:
For the last project, the client and the IDEO team created a fully immersive story-based experience. They prototyped a truck, had projections on the walls, actors reading a script, and audio effects generating a sense of weather.
This experience brought together a disparate client group of designers, engineers, and marketers and the previously siloed departments started communicating in a new way. By telling this immersive story, the team found a way to elevate the work above what was initially perceived as affecting only certain groups within the company. People would say, that’s a piece of engineering and applies to my department, or, that’s a piece of marketing and applies to their department. The story managed to raise everybody up to have a conversation about the overall experience.
Now that's a lot. Prototype a truck?! Stoping well short of pyrotechnics, we often have other things that can guide our larger product community on to a sense of the journey we're taking toward a particular product vision. We share story maps, customer/user journeys, sketches or high fidelity prototypes, which personas we're targeting, data we've analyzed... the list goes on. As a coach, I like to work with the team to embed these artifacts into that lucid narrative I mentioned earlier.
This brings up an interesting point; sharing is a venue where team members get to practice important business and social skills. You have to write the story and present it in front of a small audience after all.
We share deliveries and discoveries alike. We also share learnings around team building and the new skills its individuals are building. Don't showcase features. Do showcase the team's growth. How did you apply feedback from previous sharing events Demonstrate iteration!
When the team is done sharing, it's time to collect feedback. I am pretty insistent that the team be given the chance to present their learnings, discoveries, and output before we receive any executive notes. On the team side, I ask that they not make any commitments around scope or direction in that sharing meeting. We're trying to build fully autonomous product teams and it's important they begin shot-calling with data versus committing to single influential people higher up on the org chart.
Effective Challenge Shares
A few tips and tricks to getting the most out of this session:
Prepare, prepare, prepare. Prepare the team going into a sharing event. What are we presenting and in what order? Are we presenting in a natural order or are there jarring non-sequiturs in the way we're stacking the news? What might we present from discovery alongside delivery? How much time do we need to present each topic? Who should present or co-present this? Who hasn't presented in a while (or ever)?
Setup the etiquette of the share. When the team is gathered with its stakeholders, remind them of the "no commitments" rule I described above. I find a perfectly acceptable answer is, "thank you for your feedback." I encourage teams to only ask clarifying questions. Debate, negotiation, and unilateral commitment are to be avoided. The team has a planning session coming up in an hour or so where they can consider the feedback they were offered.
Take notes, relentlessly. Speaking of feedback, you need a way of collecting the comments, suggestions, praise, and questions that were raised in the sharing session. Rather than appoint a single "scribe," have everyone on the team capture the feedback that stands out to them. Chances are there will be multiple interpretations of any feedback item and those interpretations can sometimes lead to interesting conversations that end up mattering.
In my next post, I'll share how I like to reflect on this feedback and pivot our plans based this feedback. Remember: hyper-sprints are a loop. The most productive hyper-sprint creates a feedback loop that influences our decision making, behavior & choices, and clarity on our target outcomes.