How to Swarm

Slice

Plan

Collaborate

Deploy and Celebrate

Repeat

Slice

Slice

As a team:

• Decide on several slices for the swarm.
• Shoot for 30-minute slices. (You'll be wrong.)
• Every slice should make a visible / testable difference.
• Schedule a bit more than you think you can do in the swarm

Plan

As a team, for each slice, agree on

• how any new UI should look
• the types and structure for any new data
• what files will need to be edited, created, or refactored

Collaborate

• Swarm on discussions, show-stopping bugs. Subgroup on subtasks of common deliverable.
• Rotate! Everyone gets at least one turn every swarm.
• Agree on whether person at keyboard is Mob programming typist or Pair programming driver

Timebox

• Avoid sessions with no deliverable
  
• Set alarms to limit discussions to at most 15 minutes
• Limit fixing a bug similarly
  • If fix in progress, change swarm goal, finish fix outside swarm
  • If no fix in sight, do Plan B (something simpler)

Deploy and Celebrate

• As soon as something works,
  • deploy to public site and verify
  • push to Github and announce
  • all team members pull changes
  • high five / blow a horn / ...

When to swarm

• At least twice a week
  • More if swarms are not 100% of team
• Several days apart
• More than hour, less than three

What to swarm

Everything that affects everyone.

• UI design. Database schema. Component API.
• Product goals: What to add. What to fix. When to refactor.

Safe to solo

Local well-defined team-discussed changes.

• Implementing bug fixes
• Adding error checking
• Cleaning or adding data

Branch

• Create a new branch for each slice, to
  • avoid conflicts with other subgroups
  • share half-done code within subgroup
• [Optional] Use pull requests to merge branches.
• Delete branch as soon as code is deployed and merged.
• More on branching models