AoAD2 Chapter: Collaboration (Introduction)
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.
Collaboration
In addition to the teamwork expected of any Agile team (see the “Teamwork” chapter), Delivering teams also have high standards of technical excellence and collaboration. They’re expected to work together to keep internal quality high and deliver their most important business priority.
These practices will help your team collaborate:
The “Collective Code Ownership” practice encourages team members to improve each other's code.
The “Pair Programming” practice cross-pollinates ideas and helps team members understand each other’s work.
The “Mob Programming” practice gets your whole team working together.
The “Ubiquitous Language” practice helps team members understand one another.
Collaboration Sources
As is typical for the Delivering zone, most of the practices in this chapter trace their lineage back to XP.1 Collective Code Ownership and Pair Programming both come directly from XP.
1XP’s inspirations extend further back still, of course. One particularly noteworthy predecessor is Ward Cunningham’s EPISODES pattern language [Cunningham1995], which includes many ideas, including pair programming, that later made their way into XP.
Mob Programming is a variant of pair programming. It was formalized as a practice by Woody Zuill, based on his experiences of using it with a team at Hunter Industries. Woody’s original name for the practice was “Whole Team programming,” but he had used the name “mob programming” for a similar activity (from [Hohman2002]), and that’s the name that stuck. It’s also known as ensemble programming.
I first learned of Ubiquitous Language from Joshua Kerievsky, who included it in his Industrial XP method [Kerievsky2005]. It was a replacement for XP’s “Metaphor” practice, which didn’t work well and ended up being removed from XP’s 2nd edition. I’m fairly certain Kerievsky’s inspiration was Eric Evans’s excellent book, Domain-Driven Design: Tackling Complexity in the Heart of Software.[Evans2003] Evans’s book is the basis for my discussion.
Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. For videos and interviews regarding the book, see the book club archive.
For more excerpts from the book, see the Second Edition home page.