3 Amigos
Bug bash
Ensemble programming
Ensemble testing
Feature kick-off
Mob programming
Pair programming
Pair testing
Software teaming
Swarming
Variations
3 Amigos
Product + Dev + QA discuss work increments
- Does not involve the whole team
- Make the acceptance criteria SMART
- Uncover missing or extraneous acceptance criteria
- Make risks explicit which are not covered by the acceptance criteria
Bug bash
The whole team performs exploratory testing together
- Could choose to do one before a major release
- Should not be done on untested code or code with many known issues
- Clearly communicate the scope of the bug bash
- Assign people to areas of functionality or type of risk
- Make it double as a fun, cross-functional bonding experience
For a variation, see Ensemble testing.
Ensemble programming
The whole team working on one thing at one keyboard
Advantages
- Best of all your abilities
- Better code quality
- More diverse design options
- Issues resolved more quickly
- Knowledge transfer
- Shared course of action
- Continuous code review
- Higher satisfaction
- Builds better communicators
Disadvantages
- Can be slower than the whole team working in parallel
- Requires interaction with many others
- active involvement
- good communication
- empathy
- Doing it remotely is difficult
What a Driver can do
- Ask to hear from voices they’re not hearing much from
- Point out code that’s long / complex / misnamed / duplicated
- Ask for more (or less) detail about what to type
- Suggest an improvement for the ensemble’s consideration
- Try to use a new IDE feature, shortcut, or tool that could help
- Celebrate a good result, elegant solution, or helpful contribution
- Give extra support to contributions of more junior team members
What a Navigator can do
- Filter ideas and suggestions into concrete things to type
- Suggest unit test scenarios and using Red, Green, Refactor
- Find & share relevant information from documentation & web
- Point out repetitive tasks that could be automated
- Get ideas from the group, especially from quieter voices
- Amplify the perspectives of non-programmers
- Move a stalled discussion forward by making a bad suggestion
- Listen actively, ready to pitch in when needed
- Ask questions to make sure you know exactly what’s happening
- Draw out a possible solution or alternatives on a whiteboard
- Record notes about things to remember or investigate
Resources
A day of Mob Programming - Woody Zuill (YouTube)
Remote mob programming guide (external website)
Mob Programming - the Good, the Bad and the Great. (external website)
Ensemble testing
The whole team joins in a test activity
Compared to ensemble programming
- Also involves the whole team
- Involves the same techniques
- Can be used as an exploratory bug bash
- Can be used to improve or write test automation
Feature kick-off
Whiteboard technical solution / discuss how to test
Compared to ensemble programming
- Does not involve the whole team
- May whiteboard possible solutions
- May define a back-end/front-end contract
- Generate test scenarios and how to test them
Mob programming
Pair programming
Two developers working on one thing at one keyboard
Advantages
- Best of both your abilities
- Better code quality
- More diverse design options
- Issues resolved more quickly
- Knowledge transfer
- Shared course of action
- Continuous code review
- Higher satisfaction
- Builds better communicators
Disadvantages
- Can be slower than working on two things in parallel
- Requires interaction with another human being (active involvement, good communication, empathy)
- Synchronous, requires a call or sit-together
How to start
- Set expectations low. It’s like paddling a tandem canoe. It’s easier to keep a canoe straight with two people paddling, but it will take time to learn to work well with another person.
- Be physically at the same desk. You can pair program remotely just fine, but preferably not on the first try.
- Agree on how you’re going to do it before you start doing it. Which pairing style? Switch roles? Stop when? Pause when? Split tasks and return to pairing when?
Resources
Pair testing
A developer and a tester testing at one keyboard
Advantages
- Efficient test-fix-retest cycle
- Creates developer-tester rapport
- Spreads test techniques & thinking
- Knowledge sharing (development)
- Knowledge sharing (product)
Disadvantages
- Requires interaction with another human being
- active involvement
- effective communication
- empathy
- Synchronous, requires a call or sit-together
How to start
- Try the strong pairing technique first, where the person most skilled in testing provides test scenarios, ideas, questions to the person at the keyboard.
- Pair early, before even code reviews have been started - it will make up for potential retesting time after code review comments
- Measure cycle time for similarly sized tickets when they are versus when they are not pair tested
Resources
Styles of Pair Testing - Maaret Pyhäjärvi (YouTube)
Software teaming
Swarming
Temporarily have the whole team working on one urgent item
Compared to ensemble programming
- Also involves the whole team
- Temporary
- Less structured
Variations
For pairing on large tickets
- You can go async, for example for bigger bug fixes or compatibility testing, and return to working together.
- You can loosely pair, keeping audio open (or sitting at adjacent desks) until converging again.
For pair programming
- The Navigator telling the Driver exactly what to type versus the Driver explaining what they’ll do next
- Regularly switching roles versus not switching roles
- “For an idea to go from your head into the computer, it MUST go through someone else's hands” versus 2 keyboards, 1 problem
- Fixed schedule of breaks and rotation versus freestyle
- One person writes tests, the other makes them pass (using the Ping Pong approach or with fixed roles)
For ensemble programming regularly
- You can do it sometimes, such as one day per Sprint or for specific tickets that involve the whole team.
- You can do it always, with individuals stepping out regularly for relief from so much interaction.