2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- December 28, 2016
- Collaborate
I was talking to some friends at Agile 2016 about which they thought was more effective, pair programming done well or mob programming done well, but we ended up deciding that the jury is still out on this question, at least for the time being.
In terms of learning and spreading knowledge across a team we felt that both pairing and mobbing were comparable, with mobbing a bit more efficient. The same, we felt, is true for the quality of code produced, with both paring and mobbing yielding significantly higher code quality than software developed by a programmer working alone.
But in terms of productivity we weren’t sure which was better. We thought it probably depends upon the team and the type of problem they’re solving.
I find that pairing done well can be much more productive than having developers work by themselves. We’re far less likely to make mistakes and introduce bugs into code when we work in pairs.
Debugging is still the number one time sink in developing software so if we can reduce the time required by debugging by writing fewer bugs, it can greatly boost the amount of features we can deliver.
I have personally not had enough experience with mob programming to get a sense of how productive a team can be when they’re working with the same problem at the same time but I do have a lot of experience with pair programming and I am always surprised at how much more productive we can be together than just working on our own.
One might think that mob programming is highly inefficient because the whole team is working on the same story at the same time but it turns out there are a lot of parallel tasks that can be worked on by different team members as a story is being implemented. The result is that most everyone is engaged most of the time when mobbing. To see a time lapse video of a team mobbing for a day condensed into five minutes, visit http://mobprogramming.org/mob-programming-time-lapse-video-a-day-of-mob-programming/.
In my experience, as soon as you have people start to work together they spend much more time focused on solving problems and much less time doing other things. Pair programming boosts productivity on any team—as long as they learn how to do it well.
Writing software can be a personal activity so learning how to build software collaboratively and out of a conversation rather than out of our heads can be a different skill set for some developers, but the benefits can be enormous. Pairing and mobbing are the fastest ways I know to propagate knowledge across a team, improve quality, and reinforce new habits.
I have heard a lot of people’s opinion about pairing and mobbing who have never tried either and I know from my own experiences that actually doing pairing is very different than I thought it would be like. So what about your experiences? Have you successfully done pairing or mobbing? Did you feel the team’s productivity increased or decreased?
Previous Post: « Time Box to Scope Box
Next Post: Ping-Pong Pairing »