Unveiling the Human Element in Google Sprints: A Tale of Two Teams

It’s the heat of a hackathon, everyone's a buzz of energy. The clock is ticking, and you find yourself in as a facilitator for not one, but two diverse teams. But this isn't just another chronicle of the ups and downs of a hackathon. It's a deep dive into the human-centred design of Google Sprints, drawing lessons from two starkly different team dynamics.

I recently had the unique opportunity to lead two teams at a Hackathon. With little time and two teams comprised of mostly people I had never worked with before, I figured why not try a Google Sprint.. twice.

Why Google Sprints? Why Now?

The concept is no stranger to me. My history with Google Sprints is rich and varied, sprinkled with experiences that range from sheer inspiration to 'back-to-the-drawing-board' kind of scenarios. For those who don’t know, the sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed by Jake Knapp (former Design Partner at GV), it’s business strategy, innovation, behaviour science and design thinking packaged into a process that any team can use. This hackathon posed a new question: How does Google's, highly structured methodology hold up in a frenetic hackathon environment?

Tweaking Google Sprints for a Hackathon

It's like cooking your favourite recipe but in half the time and maybe with a few substitute ingredients. Google Sprint is structured for week-long engagements, yet the hackathon presented a time-compressed scenario. The adaptability was key, as I had to rework the entire methodology into a 3-week, 3-hour-per-week format.

Key Challenges

• Experts with different context
  In the ideal world of Sprints, you’d already understand the problem and be able to identify the skills and expertise needed to tackle it. In this particular case, teams were generally unbalanced, mixed between varied business propositions or just missing key experts who could solve these problems effectively.

• Large teams
  A typical sprint team is around 5 to 7 people. This is large enough to bring in diverse viewpoints but small enough to keep the process efficient. The teams I ended up leading consisted of 10 and 11 people respectively which led to a few quiet voices being drowned out.

• Time? What time?
  Condensing 5 full working days into 9 hours over three weeks came with its sacrifices. Most notably, the prototypes produced by both teams were not customer-tested. Oops.

So how did it go?

Team 1: The Dream Team

Imagine you're trying to create a piece of music, and every musician in your band knows precisely when to chime in. This first team was akin to that musical nirvana. Members eagerly volunteered for tasks that played to their strengths, and there was a general air of camaraderie and mutual respect. However, like any real-world scenario, the team's zest sometimes eclipsed the contributions of quieter team members. We adapted by identifying this human factor and redistributing roles to foster inclusivity.

Team 2: The Misfit Puzzle

Before the first meeting, whispers filled the air about a 'difficult team member' and when we kicked off, the rumour came to life. The attendance issue was a substantial hurdle, as key players missing meetings meant we lost a lot of time simply getting them up to speed. Beyond the logistical nightmares of key players playing truant, the real challenge lay in the misalignment of personalities and lack of a shared vision, precisely contrary to the human-centred ethos of Google Sprints. While we delivered a presentation and a well-thought, problem-solving prototype in the end, it did not come without challenges.

It's All About Balance

The two teams stood as living testaments to the criticality of human elements in Google Sprints.

• Team composition isn't just about skills; it's about the harmony of human factors.
  The first team was naturally predisposed to the methodology, while the second team was not. A harmonious blend of skills and personalities can make or break a sprint.

• Active engagement can make or break a project.
  The high level of commitment in the first team enabled a seamless workflow, while the sporadic engagement in the second team hampered progress.

• A facilitator can only do so much when the human variables are awry.
  While a facilitator can guide and support, the team's dynamics and makeup play a significant role in determining the success of a sprint.

Where I Could Have Been More Human-Centered

Three days after I put my hand up to lead the teams I ruptured my Achilles tendon playing basketball, so let’s just say I wasn’t in peak form to lead two teams. Regardless, I reached out to the teams post-hackathon to understand how it went as well as my performance. Here’s what I could have done better:

• Engaging the less vocal individuals to contribute their unique perspectives.

• Reinforcing the human need for reliability and consistent attendance.

• Choosing to focus on a single team to offer a more balanced human approach.

Do I recommend a Google Sprint for a Hackathon?

Ultimately, The Dream Team won the Hackathon, but I wouldn't say that the Google Sprint was the key factor. The team's composition and personalities were what carried the project from idea to victory. Here are some factors to consider if you're thinking of using a Google Sprint for a hackathon:

• Team
  A well-rounded team with a diverse set of skills and expertise is essential for success. If you have the time and ability to hand-pick your team, I highly recommend it. However, if you're stuck with the team you're given, try to work with them to build a strong working relationship.

• Time
  The Google Sprint is typically a five-day process, but it can be compressed into a shorter period of time. However, if you compress it too much, you may not have enough time to complete all of the steps effectively. I would recommend at least three working days for a Google Sprint hackathon.

• Facilitator
  The facilitator is responsible for leading the Google Sprint and ensuring that it runs smoothly. If the facilitator is not experienced or knowledgeable about the Google Sprint process, the sprint may not be successful.

Closing Thoughts

So, will I embrace Google Sprints in the future? Absolutely. However, my future endeavours will carry a fresh layer of human-centred wisdom, carefully harvested from this recent experience.