Skip to content

Method / Playbook · 4 min read

Sparring

Sparring is a way to get prompt and candid feedback on your work from others in your team. Use it to battle test your ideas by exposing them to differing points of view, and/or get clarity on gaps you can’t fill on your own.

Prep time: 10 minutes Duration: 30-60 minutes Participants: 2-6

Introduction

Sparring is a meeting-based method to get feedback on your work from others in your team. Use this play to battle test your ideas or work in progress by exposing it to different points of view. Sparring can be a highly effective way to identify and remedy gaps in a real-time collaborative setting.

While sparring isn’t confined to any particular discipline or stage of the product development lifecycle, it’s especially helpful when it comes to firming up a solution design or technical specification such as a database schema, or design system component API. You can also spar on a product strategy, or high-level architecture, or anything really.

Sparring sessions are usually initiated by the person doing the work, but they can also be requested by another team member who may want to understand or or give feedback on something you’re working on.

Frequency

In high-sync work settings like at Thinkmill, we’ve found that sparring is typically undertaken on a regular (daily-to-weekly) basis. In fact, it’s an integral part of how we keep in sync. If your team or project environment does not embrace working in parallel as much, that’s okay, sparring can still be very useful when the path to solving a problem lies with your broader team.

People & participants

Generally speaking, the amount of prep required is:

  • proportional to the number of participants, and
  • inversely proportional to the amount of context the participants hold

To put it another way, if your sparring group is meeting regularly you can probably pick up where you last left off. If it’s been a while, or you have a big group of participants, you may want to make an agenda to get the most of your time.

<aside> 💡 Pro-tip: as a general rule of thumb, try to keep sparring sessions to 6 or fewer participants to encourage engagement

</aside>

To get the most out of sparring sessions, we suggest you frame out in advance:

  • what you want to get out of the session
  • where feedback is needed
  • where it is not needed (just as important)

Sharing your objectives and the bounds of interaction with colleagues up-front should make for a smoother and more productive session.

Documenting progress

Sparring often necessitates a divergent mode of collaborating in order to evaluate topics from many different angles. While this mode of working is important and essential, it can have a negative impact on your session’s desired outcomes you don’t keep it in check.

Where possible, “close out” sparring topics by clearly documenting the decisions and follow up actions that stem from the feedback. The activity of writing it down is in itself convergent, and acts as a nice breather for the participants before you move on to the next topic.

Here’s an example decision log from sparring session:

DecisionsActions
We should include a revert to saved action within the field component (now that we indicate there are staged changes in the system).Update related Figma components to include the revert to saved button.
The use of staged as a label is not user friendly enough.Identify a more user friendly label to reflect unsaved changes.

On the value of sparring early in the project lifecycle

To produce high-quality, performant and maintainable software, the underlying solution design needs to be well thought through with the right design and technology choices and a sensible approach for how to deliver them. Many of the decisions that feed into the solution design are made early in the project, and sometimes these decisions land before all the basic requirements are fully understood.

While software is an inherently malleable, the process of making it is very labour intensive. Correcting solution designs and technology choices down the track can become a major undertaking (by some estimates, fixing defects late in a project can be 50-200 times costlier than catching them early).

As a result, sensible, informed decision making during the initial solution design plays a big part in efficient development processes. Time spent understanding the potential effects of solution design choices early, is time invested in the quality and maintainability what you deliver in the long run.

We’ve found sparring to be one of the plays we use most to ensure that the most important, difficult to change decisions being made are the right ones, to provide a solid foundation from which to build the future.

Resources

Chat to the following people to learn more about this play:

Giselle Stidston avatar Giselle Stidston avatar

Giselle Stidston

@GiselleStidston (opens in new window)

Giselle is a designer who loves learning about new problem spaces. She knows how to solve cryptic crosswords and has a knack for expressing things as diagrams.

Ronald Aveling avatar Ronald Aveling avatar

Ronald Aveling

@ronaldaveling (opens in new window)

Ronald is a designer with a soft spot for systems and structured content. Knows the difference between Tofu and Tempeh. Makes a damn good brunch.

Get playbook updates

For updates on future playbook publications, subscribe to our newsletter.

Related plays

A photo of Jed Watson & Boris Bozic together A photo of Jed Watson & Boris Bozic together

We’d love to work with you

Have a chat with one of our co-founders, Jed or Boris, about how Thinkmill can support your organisation’s software ambitions.

Contact us