Teaming Challenges

Even when the team has set up correctly and is following the rules, teaming sessions hit predictable challenges. None of these mean the practice is broken; they mean the team is hitting normal growth pains.

1. Navigator-to-Driver Communication

When the navigator and driver are at different levels, telling the driver what to do can stall.

How to handle it:

1. State intent. Describe clearly what you want the driver to achieve before any keystrokes (e.g. "Now we need to extract this into a function").
2. Give location. If the driver is sure what to do, direct them to where you want them to go (e.g. "Go to line 482" or "Click the menu bar then the Actions button").
3. Give keystrokes. If the driver is still uncertain, define the exact keystrokes. Useful in advanced scenarios where keyboard shortcuts speed things up.
4. Patience is a virtue. This will feel difficult at first as the driver is learning. Over time the knowledge gaps in the team will disappear — that is one of the core benefits of teaming.

2. The Navigator Is Confused

Standing up as the navigator when working on something unfamiliar is daunting. People freeze.

How to handle it:

1. Provide hints from the mob. Anyone in the mob can suggest what the next step might be. Ask questions rather than direct — e.g. "Do you think we need a test here?"
2. Show respect. Help rather than judge. Everyone has areas they can improve, and at some point you will be the one navigating something unfamiliar.

3. Only One Person Knows What to Do

When a single team member has all the context, the rotation can feel pointless.

How to handle it:

1. Allow the knowledgeable person to act as navigator. Keep the rotation but let them stay in the navigator role across multiple driver rotations, regardless of where they are sitting.
2. Skip the driver position for them. The knowledgeable person should not take the keyboard — this is a learning opportunity for everyone else, who get to drive while the expert directs.

4. Different Opinions

You will have different opinions when the navigator is defining what to do. Speaking up will distract the navigator and undermine their confidence.

How to handle it:

1. "That's not a good way of doing things." If it is really important, note it down for the retro at the end. Do not interrupt mid-rotation.
2. Refactor but do not rewrite. When it is your turn as navigator, do not delete the previous person's work. Pick one aspect to improve (performance, readability, or maintainability), make that change, and no more.

5. Code Quality Slips Past

If you can't interrupt a navigator, sometimes bad code makes it into the codebase.

How to handle it:

1. Note it for the retro. This is the same problem as each person working separately, except now the team can notice the issue and discuss it together.
2. Suggest a focused training session. If the team has identified a knowledge gap, propose that the next teaming session focuses on a dojo or other technique to teach that specific practice. Congratulations: the team has found and addressed a gap in record time.

Next Step

Some patterns will sink a session before it gets started. Read Anti-patterns to recognise them.