Scouting – A Technique for Settling Pair Programming Disputes

Pair programming is a technique commonly used within modern software development teams. It leverages the power of two minds working collectively to arrive at optimal solutions. Anyone who has engaged in pair programming knows that the process often gives rise to disputes where both parties have differing ideas on the best way to tackle a given problem. While this may seem like a drawback, it is, in fact, by design. The cycle of facing a problem, ideating solutions, disagreeing, and then building alignment is where much of the value in pairing lies.

Disagreements and disputes will occur, but they don’t have to result in a gridlock that stifles forward progress. Provided team members have the right tools to resolve the situation, disagreements can lead to even stronger solutions. In this post, I’ll describe a technique I call Scouting, which can be used for just that.

Getting to Know Scouting

The term “scouting” stems from the military tactic of sending out one or more scouts to unknown areas, aiming to gather intelligence and inform better decision-making about the potential paths ahead. This concept finds a parallel in pair programming when team members face disagreements or are unsure about the best way forward.

When this occurs, participants temporarily venture down and explore their own paths, much like tactically dispatched scouts. The aim here is not to create a polished solution in isolation but to independently frame or spike out their believed best course of action within a fixed timeframe.

While Scouting, developers produce rapidly crafted, somewhat rough code with the intent of quickly fleshing out ideas in a tangible form. Once the scouting time concludes, akin to the tactical scouts returning to their unit, the team members regroup. Armed with fresh perspectives and unique insights, they subsequently present and discuss their findings, enabling a more informed and collective decision to be made on the most favorable path forward.

Divergent and Convergent Thinking

The twin concepts of divergent and convergent thinking lie at the heart of Scouting. Initially, the programmers diverge to explore different pathways, generating multiple solutions. They then converge on their findings, aligning on the most favorable outcome. Like in many creative pursuits, this ebb and flow of divergence and convergence leads to innovative and robust solutions.

More Than A Technique, It’s A Mindset

When using Scouting, both parties must enter into the process with the proper mindset. As with scouts in a military setting, coders using this tactic aren’t setting out to prove their preconceived notions at all costs. In other words, they shouldn’t be married to their idea. Instead, they are seeking to discern reality.

Scouting isn’t about asserting one’s dominance; instead, it encourages an open and growth-oriented mindset. It requires acknowledging that both ideas on the table involve unknowns that the process will uncover. It encourages exploring multiple routes, uncovering potential roadblocks, and gaining a clearer understanding of the implications of each possibility.

Tip: Keep the timeframe short.

To further support this mindset, constrain scouting to the shortest possible time allocation. The more time each person has to flesh out their solution, the harder it becomes to emotionally detach from it. Initially, try limiting your scouting to 30 minutes.

Scouting in Action

In scouting, the focus isn’t on the volume of code but the code’s efficiency – the shortest possible code to validate or invalidate an idea. This brief journey into the wilderness of coding and your return with findings facilitate meaningful discussions with your peer. It’s fine to think of the code you produce as throw-away code because it still has served its purpose: uncovering unknowns and building alignment.

It’s important to understand that scouting is not a divide-and-conquer technique. When dividing and conquering, both parties would be expected to come back to the table having completed some aspect of a common feature. For example, one person builds a UI component while the other implements a related API request. While that may be a useful technique, that’s different than scouting.

When to Use Scouting

Scouting is not a silver bullet for solving all pair programming challenges. In fact, a disciplined pair should be able to resolve many differences and find alignment in many cases through simple dialogue. However, in my experience, there are instances where one can not see far enough ahead to be convinced of the right path forward without having something tangible to look at and/or poke at. That’s when you know it’s time to try scouting.

Steps to Embrace Scouting

Ready to implement scouting in your programming workflow? Walk through these steps:

  1. Ensure that both peers understand scouting’s philosophy. (hint hint – share this blog post!)
  2. Align on the problem that you’re solving.
  3. Set a tangible time limit for individual Scouting expeditions.
  4. Begin your Scouting journey – code, explore, and learn.
  5. Regroup to share your individual findings, discuss, align on the best solution, and proceed collectively.
  6. Incorporate scouting into your pairing tool belt and use it when necessary.

Pair Programming Dispute? Try Scouting

Pair programming thrives on the interplay of ideas, where an occasional clash of differing perspectives isn’t a setback, but rather a catalyst for more robust solutions. The technique of scouting, inspired by military practices, provides an effective pathway to exploring these unique perspectives independently. It encourages developers to step out into unchartered territories, armed with their coding knowledge and an open, growth-oriented mindset. By venturing out, coders unravel hidden insights, uncover potential pitfalls, and pave the way toward a clearer understanding of the programming terrain.

Remember, scouting is not a substitute for constructive dialogue, but rather a complementary tool providing tangible findings when discussions hit a bottleneck. The process, kept agile with short timeframes, becomes an informative expedition enhancing the pair programming experience. Like a reconnaissance scout reporting back with valuable intelligence, Scouting equips developers with enlightened perspectives, contributing to a collective route forward.

Conversation

Join the conversation

Your email address will not be published. Required fields are marked *