This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.
- Whole Team
We bring the insights of the whole team to bear.
In the early days of Extreme Programming, when pair programming first became popular, people used to mock it. “If pairing is good, why not triple!” they laughed. “Or just put the whole team in front of one computer!”
They were trying to put down XP, but the Agile way is to experiment, learn, and improve. Rather than assume something won’t work, we try an experiment. Some experiments work; some don’t. Either way, we share what we learn.
That’s what happened with mob programming. Woody Zuill had a group teaching technique he used for coding dojos. His team at Hunter Industries was in a bind. They decided to try Woody’s group technique on real-world work and put the whole team in front of one computer.
It worked, and worked well. Woody and the team shared what they learned. And now mob programming is used around the world.
In some parts of the world, the term “mob programming” has unpleasant connotations, so people call it ensemble programming instead. Woody Zuill’s original name for it was “Whole Team programming.” But, he says, “I have always said, I don’t care what it’s called. Learning to work well as a team is worthwhile and I invite people to call it what they will.”1
1Quoted from a conversation with Woody Zuill on Twitter.
...to continue reading, buy the book!
In this Section
- Mob Programming
- How to Mob
- Why Mobbing Works
- The Mobbing Station
- Making Mobbing Work
- Team dynamics
- Energized work
- Strict navigator role
- Mini-mobs and part-time mobs
- Alternatives and Experiments
- Further Reading