For remote, globally distributed teams like the Mozilla l10n-drivers, time where we can be together in person is precious. For a couple of years, those opportunities have been restricted to the bi-annual Mozilla All Hands, but there was a noticeable gap in our team’s work and unity that meeting twice per year wasn’t filling. Last week marked the first of our revived team retreats (aka work weeks, off-sites, etc.) in Reykjavík, Iceland!
My goals for this retreat were two-fold:
- Create an environment of radical participation from each member of the team.
- Create an environment that made sharing and collaboration the modus operandi among members of the team.
I wasn’t too concerned about producing something during the work week, mostly because we’ve been highly goal-oriented and decisive since April, 2016. My biggest concern was that this retreat would be the same as past retreats: separated groups working on their own projects, individuals performing their day-to-day tasks, and three individuals attempting to have conversations and make decisions that impact the whole team without their attention. I wanted this practice to remain a relic of the past and to find a format for this retreat that would accomplish my two goals.
After some research, I discovered Jake Knapps’s, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, a product of years of experience coming out of facilitating brainstorming, prototyping, and testing of new ideas from start-up teams within the Google Ventures family of investments. Within a Jake Knapp-style Sprint, you dedicate five days to solving a large problem as a team of people with defined roles. Each day is spent on attacking the problem as a team:
- Day 1 – Map the problem, set a long-term goal, establish sprint questions, and define a target.
- Day 2 – Sketch the problem and possible solutions.
- Day 3 – Decide on the solution to prototype and storyboard it.
- Day 4 – Develop the prototype.
- Day 5 – Test the prototype.
Each day a Facilitator guides the team through the process, writing on whiteboards throughout the workspace and encouraging others to write notes and ideas on post-its and stick them on the walls. This allowed for each of us to engage with the space and our own spatial reasoning to improve and funnel our though processes. The process includes various games to foster creativity and brainstorming, putting pen to paper to draw out ideas, dot-voting, and more. The end result is a solution to a problem that has been brainstormed, scoped, prototyped, and even tested.
In our Sprint, since I had proposed the Sprint and done the research, I played the role of Facilitator. I know that it’s “against the rules” but because of my role on the team I also needed to be the Decider. I wasn’t thrilled with the idea of holding both roles. I would have preferred turning these into rotating roles: should this Sprint be successful, then the next Sprint would see different people as Facilitator & Decider. We made it work though.
Here’s the breakdown of our Sprint details:
- Problem: No visibility of l10n-driver projects.
- Long-term goal: L10n-driver information is created, maintained, dynamic, and discoverable.
- Sprint questions:
- Can we make sure our statuses are regularly up-to-date?
- Will we use whatever solution we come up with?
We tailored our Sprint to the time we had available. The plan was to start day 1 on Tuesday and move through to day 4 on Friday. We all agreed that testing could be done over the course of the following week. We also agreed to one of the more controversial rules of the Sprint for the first 3 days: no devices. During our breaks, devices were allowed, but generally we kept the laptops closed.
We rented an AirBNB in Reykjavík for us to share and used the common areas of the house as our work space. Why Reykjavík, you might ask? It’s central for our team (allowing us all to share the jet lag equally), easy to find an AirBNB big enough for all of us, and since I’ve been there many times before, I was able to ensure that our costs on the ground were kept to a comparable level as Toronto and other major cities (thank you Bónus market and skyr!).
Entering our Sprint week we experienced breakthroughs on a number of projects that we’d been blocked on for months. This meant that there was not only pressure to come up with a solution to our problem, but a to ensure that we can make progress on these blocked projects and best utilize any new resources we’d be given to do so. In addition to the time we spent on the Sprint during the day, we had to spend nights holding breakout sessions to address these breakthroughs. At the end of the week, we had a long post-mortem discussion on the utility of the Sprint format for our work weeks.
Generally speaking, the Sprint was hard, exhausting, productive, and positive. It required a huge amount of focus from each individual on the task at hand. Without devices to distract us, all of our faculties were required at every moment. This led to deep discussions on the issue and, ultimately, a tired group by the end of the day. It also led to one of the most collaborative work weeks the l10n-drivers had ever experienced.
The end product wasn’t the end goal of this experiment. So how did we do with the primary goals of the experiment?
With no devices to distract us and prescribed methods of participation (i.e., sketching, mapping, dot-voting, etc.), the environment started with a foundational obligation that each member participate fully in the process, an obligation to which each l10n-driver rose to meet. In addition to this, renting a shared home for lodging, meals, and working created a safe environment for each of us to engage in. We not only bonded through the close proximity but within that bonding, a sense of security and safety was cultivated ensuring that each viewpoint was treated with equal respect and consideration. I absolutely feel that this format created an environment of radical individual participation that empowered sharing and collaboration among the team.
We learned in the first day of our Sprint that we’d defined a problem that was way too big. Mapping the problem out helped us to narrow our focus of the problem down the act of l10n-drivers submitting regular reports in a single workflow, but we learned that even this was too broad. It seems that there are good use cases for the Sprint and bad ones. Our problem seems to indicate that we experienced a “sort-of” bad use case. The exercises were valuable, but the end solution to the problem wasn’t ideal. Many of us observed that, while this format is great for solving problems, it may not be suited to the bi-annual retreats we’ll be having. Rather, it seems that this is best suited for bringing together a cross-functional team to contribute a solution to a problem that is a component of a larger project (e.g., what does an MQM-based review mechanism look like in Pontoon?).
Balancing Obligations & Time Management
We had many priorities competing for our time going into this Sprint. There was the priority we’d placed on participating in the experiment and then there were the breakthroughs we experienced the week before that demanded prioritization. We started by trying to condense a full Sprint day into a morning and using the afternoon to address these breakthroughs. This simply didn’t work. Instead, we worked late into the night each night and during meals to address all of these obligations, making a lot of us tired throughout the week. On Thursday, after we’d gone through the decision and storyboarding activities of day 3, we decided it was a good stopping place to evaluate how we’d been spending our time. Luckily, we’d finished day 3 by about 2PM and could spend the rest of the day on breakouts. After dinner, we reconvened to discuss how we would spend our final day together: on the external priorities or on prototyping our solution. In the end, we decided that the external priorities demanded our attention more than prototyping, and we spend Friday deep in breakout sessions.
Building Something from Raw Materials
Despite knowing that this would be the end result of the Sprint, it seems it didn’t really sink in until the moment we’d proposed creating something new. I suppose I’d always assumed that we could prototype using an existing solution and that the testing would be on the process/workflow within that existing solution. Instead we ended up with another project to add to our backlog, which is ultimately counter-productive for us.
The “no devices” rule was controversial on our team in the weeks leading up to the Sprint. In the end, this was one of the main contributing factor to accomplishing our goal of collaboration and participation. The members of the team with the most concerns leading up to the Sprint ended up being the biggest advocates in favor of this rule.
Prescribed Activities are Great!
The prescribed activities within the Sprint were great and potentially have utility outside of the Sprint. They helped the team to funnel their attention on the tasks at hand. They also set a framework for ideation and decision-making that fostered creativity. The musician Jack White famously said that creativity is fostered when there are restrictions. The prescribed activities “box in” the creative process and force individuals in the group to think and work alone, but together harmoniously.
Collaboration, collaboration, collaboration!
One comment from the team during our post-mortem was that they had not seen more collaboration and participation from the l10n-drivers than they have in nearly a decade. It is clear that this is much desired from members of the team. This format does a wonderful job of facilitating that environment. Our challenge now, however, is that if this is not the chosen format for our subsequent retreats, then how do we maintain or recreate this environment in a different format?
All in all, this was a great week. If your team is facing similar collaboration challenges, I highly recommend the Sprint format for your next work week. Try it on and see how it fits.