So far, I’ve talked to each person on the team to ensure I understood their needs and expectations. I liaised with Brian, the investor for this team, on what he needed to get from this first event. Then I created an agenda and icebreaker activity to acclimate the team to interacting and expressing themselves using the Miro environment.
That leaves me with:
The team working agreement area, where I’ll need to
- help the team understand their roles
- discuss if we are using the right tools
- agree on when the team should have events and be available to each other
- help the team begin a team charter around behaviors and outcomes
- NOTE: I’ll also want to reuse this information for future team events.
- a quick discussion on planning future events and how much more we need to do to begin delivering
- a quick feedback session where the team shares feedback on how they found the event.
Here is what the final kickoff board looks like. You can find the step-by-step guide on how this event went below.
The team working agreement
Although there are four activities (roles, tools, events, behavior), I built them all in the same Miro frame. This makes it easier to allow the team to jump to the whole area when I discuss the activities that we will do. It also presents well when I export the board to PDF for a historical document later.
Roles
Leveraging Ahmed Sidky’s Agile Leadership Roles concept, I defined three basic leadership roles – Investor, Development Team and Facilitator — and then left a space to the right for any additional roles that the team may identify. I left a space below each role where the team can place their “Spirit Animal” avatar (created in the previous exercise). Then I created a stack of general accountabilities (on the small, red stickies) that the team can place under the roles.
Setup:
After:
Max and Stacey added a Technical Strategy role they wanted to own. The team agreed on the accountabilities and created the appropriate stickies.
Tools
This exercise is to create a conversation about whether we are using the right tools. The team needs to see if they expect to engage with the tools at the level we hoped and, if not, start the conversation about alternatives options.
Using a simple x/y axis measuring “fit for need” vs. “likelihood to use,” the sweet spot would be the far right, center. Anything else is an interesting conversation we need to have. Each person has one vote per tool (by ctrl+left-clicking the tools sticky), and then the team can look at the results and discuss.
Setup:
After:
Most of the votes are to the far right and center. The outliers are the 1 JIRA sticky (which was me; I won’t be using it too often) and the WhatsApp stickies. This led to a conversation about how many of the team members use WhatsApp for personal use and confusing work and personal notifications. This instigated Brian, the investor, to reconsider this solution. He promised to follow up with the team later to explore other options.
Events
The hardest part of working in different time zones can be identifying when the team can come together. To make it easy for the team, I created a graphic to show viable periods.
I also created some “event stickies” to be placed on each workday with a begin and end marker for the iteration.
Setup:
After:
The team picked the fourth day to run the review/retro/planning, as they felt it gave them the most amount of collaborative space to work and prepare for the events.
Behavior
This is a simple mechanism for a team to talk about how to handle situations.
If this thing happens, then we expect to react like this, so that we get some result we need.
I peppered some suggested topics to start (although they could change them if they felt inclined) and left a “?” card to encourage them to fill in a scenario for themselves.
Setup:
After:
The team liked and used my examples and decided that three was enough to start, as long as they could come back to this board and update it.
Planning the next events
To avoid losing momentum, we locked in dates for the upcoming definition of ready and done. I also asked the team if they had any ideas about what other tasks and outcomes were needed to begin delivering the solution. Like before in the team working agreement, I kept the two activities in the same frame.
Definition of done | Definition of ready
I kept this very simple. I reused the time zone template from before but left out the days of the week. I then asked the team to pick a day when they would be ready to participate in this event and then picked a time that worked for everyone.
Setup:
After:
Due to the familiar design, this was a short conversation. They decided to have the event on the following day at 0900 UTS +12. I added my avatar as a reminder that I had a task to set it up and invite members to the event.
When can we begin delivering?
This design is also very simple. I wanted a space that would help the team list what they think needs to happen and in what order (if appropriate), and from that conversation determine when we can begin delivering.
Setup:
After:
The team was able to list a few activities and outcomes they would need to start. The good news is that they thought they could begin in less than a week. While things will invariably change, I’m happy that the team has a shared understanding of what is happening and why.
Feedback
Last, but extremely important, is getting feedback on the session. Getting feedback is critical for two reasons. First, so that I can ensure the team is getting a high-quality interaction in this space. Second, it sets the expectation that the team is expected to be aware of and discuss how effective their interactions are. This gets its own frame as well.
To keep this simple, I ask three questions, but the team only answers the questions they feel drawn to and can add others.
Setup:
After:
The feedback is useful. Allison has mentioned that she needs to find a more secluded place to work. It’s logged as a learning opportunity for later if it becomes a barrier for her to participate with the group. Also, the team wants to reuse a lot of the material we made in the session, which is great, because that was my intention from the start.
That’s the end of this 3-part journey, where I covered how I prepare, design and execute an event for a distributed team kickoff. Though this was a fictional scenario, it demonstrated common, real-life themes that when addressed properly increase the effectiveness of a distributed event.
Those themes are:
- Preparation and early conversations are key to creating the right event.
- Design the event to teach them how to interact in the environment they are using.
- Don’t just design the activities for the delivery outcomes; design how you want the team to work together.
- Always learn from the event and allow the team to surprise you.
Conclusion
Since the inception of the practice of brainstorming, business has evolved. As you’ve learned idea generation and brainstorming evolved along with it. The most recent iteration of the practice was driven by the growth of distributed teams.
Initially, idea-generation meetings using distributed teams were fraught with potential pitfalls. This guide provides the tools agile teams need to remove the roadblocks and challenges of remote team brainstorming. Put the practices, lessons, and examples into use.
Remote team idea generation can be challenging. But thanks to the evolution of online teamwork, it no longer has to be.
We would like to say “Thank you!” to all these people and companies for sharing their experiences and contributing to this guide: Melissa Ng, Hazel Teng and Peach Nacion from MELEWI, Moses Kim from Shakuro, Joe Auslander and Karly Williams from Assurity, Sharon Koifman from DistantJob.
Written by the Miro marketing team and freelance writer Julie Joyce.
