Flash Mob Programming - Trust First

Can a small set of rules help a newly formed mob to build trust quickly?

Can the same mob then transition to more relaxed mobbing practices, turning up flow and collaboration?

Can we do this within a short session?

What is this?

This is a mob programming format aimed towards creating trust quickly and exploring both the joy and challenge of pushing for performance as a team.

We do this by coming together applying very strict rules for a short time. If these rules do their job, they create structure and space to actively listen, practice empathy and getting to know each other. Having acted out this explicit marker of trust we then free ourselves from these rules, iterating and improving as a team, enjoying the ride in pursuit of flow.

The participants collaboratively self-guide the exercise in search of the best learning opportunities for their group at that time.

The format is intended to fit into a very short time box (90 minutes), allow for remote "FlashMobs" and - over time, through experience and improvements to this text - make facilitation as easy as possible.

What's with the name?

As we all know, naming is hard. These seem to be in the right ballpark for now...

Flash Mob Programming - Because of the wish to create very short and snappy sessions (ca 90 minutes) with people that might not know each other yet. This time box places an important (surely challenging) constraint on creating trust.

Trust First Protocol - Because of the central idea of building and acting out trust by listening and creating space for empathy

Alright, how do we do this?

Over multiple rounds of mobbing we guide ourselves from strict rules to more fluid and efficient styles of communication, towards higher productivity and performance. We would expect challenges to emerge. On this path we try to find the best learning opportunities for us as a team.

Two essentials of mob programming and how we implement them:

• Turn up the good: We will run quick micro retros after short time frames to modify our way of working and to improve as a teams.
• Kindness, Consideration, Respect: All three are important for building trust, so this is basically the main purpose of the exercise. But start by thinking "In this situation, how can I make my teammates awesome".

General Structure

• Round 1: Build trust
  • Mobbing with strict communication rules
  • Self assessment and first Micro Retro
• Round 2-N: When ready, expand towards performance
  • Mobbing with current working agreement
  • Micro Retro

Round 1: Build trust

This is our working agreement for at least the first round of mobbing:

• Strict Navigation

  • 1 Navigator:
    • Communicate your thinking and your intent to the team
    • Tell driver what to do on the best level of abstraction for the driver
    • Actively ask team for help
    • Bring an idea that is already in play to its natural conclusion rather than just switching to your own
  • 1 Driver:
    • You are the smart input device for the navigator
    • Actively ask navigator for clarifications and for help
    • Give hints to the navigator to navigate on the correct level of abstraction
  • Mobbers:
    • Learn from navigator (way of thinking/problem solving/programming/communicating...)
    • Stay silent until actively asked by navigator (you can always celebrate moments of excellence)

• Empathic Mob

  • Listen closely to the navigator and practice empathy
  • Stay aware of the navigator's intent and situation
  • When you become the navigator bring that intention further towards its natural conclusion

• Explicit TDD

  • Coding happens in cycles of writing a failing test, then make it pass with the simplest solution that might work, refactor whenever necessary
  • Navigator calls out those three intentions ("Let's write a failing test.", "Let's make the test pass", "Let's check for refactorings")

• Bonus: Celebrate moments of excellence!

• Switch roles every 4 minutes

The following little utterance might help to create a tangible idea about the roles and especially about asking for help: “The wonderful thing about this is that it's no problem to be lost. The team is always there for you. As driver it is the navigators job to navigate at the right level of abstraction. As navigator you can always ask the rest of your team. And as mobber you contribute what you can contribute.”

Round 1 Retrospective

Rate yourself

• Whole team rates each of the three aspects below
  • Rate from 0 to 5 by holding up one hand
    • 0: This didn't even happen
    • 5: I could not be happier how well we did this
  • Write down the ratings of all team members

1. We applied strict navigation

   • navigators had the space to navigate and ask questions
   • navigators communicated their intent and kept everyone informed
   • drivers executed on what the navigators told them
   • mobbers did not interrupt navigators unless asked

2. We practiced empathy

   • by closely listening to the navigators we got to know their intentions and some aspects of their way of working
   • navigators felt supported by the team's willingness to give them space and being supportive when asked for help

3. We used strict TDD

   • We worked in red-green-refactor cycles
   • Navigators called out the three phases and their purpose

List your team members' ratings here:

1. We applied strict navigation:
2. We practiced empathy:
3. We used strict TDD:

Do we want more of those or do we have enough foundation to relax our communication rules? Use the micro retro to learn what the team wants.

Run a Micro Retro

I learned this retro format from Fred Zuill during a remote mob session. It turned out to be quick, very effective and leave us with a log of our team learnings.

Everybody shares two things:

1. How I feel
2. One thing I want more of ("Turn up the good")

• Every time someone shares a thing to turn up, write it into your Micro Retro text file
• Things that already have been mentioned get a '*' in front of them
• Keep list ordered by number of '*'
• Add to this file in every following Micro Retro

Example:

Micro Retro

**** Continuing the intention of the previous navigator
** Test first / TDD
** Progress as working code
The group is nice to each other

Keep this file for our big retrospective later, these are your team's most important learnings.

Rounds 2-N: When ready, expand towards performance

From here on you as a team decide what you want to focus on and how you want to evolve your way of working.

The general idea of the exercise is to introduce challenge by pushing for performance.

Use the micro retro at the end of every round to both push for performance and tackle challenges that emerge.

But keep the mantra in mind: Trust over Performance.

Round of Mobbing

Enjoy collaboration and progress. Observe how changes in your way of working affect you as a team. Become aware of emerging challenges.

Micro Retro

Run a quick Micro Retro after each round of mobbing. Try 1 minute max per participant. Faster if you think about the two questions during the round.

Focus on what you can do right away. For longer discussions we have the closing retro.

Finish with a closing retrospective

Revisit Micro Retro file.

Ask what people liked about the session, what the would like to improve, what would they be interested to another time?

Explicit questions about the Flash Mob and Trust First style of this session:

• How did you experience the focus on trust and empathy?
• Did you experience the group moving from internal focus - practicing empathy, concentrating on each other - to more focus on the task, increasing performance?

What do we think about this hypothesis: When we actively focus on building trust first we are rewarded with better whole team collaboration, learning and performance.