5 ms·

I think it's easy to feel that way, but any time I've tried to measure this objectively on teams, pairing (I can't say I've ever measured mobbing) comes out ahe

I think it's easy to feel that way, but any time I've tried to measure this objectively on teams, pairing (I can't say I've ever measured mobbing) comes out ahead, even in terms of raw velocity. There's also knock on benefits down the road as IMO with pairing / mobbing there's less of a tendency to miss edge cases and so you're less likely to have bugs that need to be revisted, which is an enormous cost savings.

helen___keller 5y ago
Even if the instant velocity of some practice is higher, the long term average velocity might not be. Which is to say, if your devs hate pair or mob programming and quit, your teams velocity is going to be greatly impacted. If devs consistently react negatively to a practice, in itself that’s evidence to be wary of the practice.
- TameAntelope 5y ago
  Then you can hire devs who are better able to build the things that you need.
- ryanbrunner 5y ago
  If devs universally react negatively to a practice, sure. If some devs don't like a practice, but it's more effective, that's an argument to ensure that you're filtering for it in hiring.
ryanmcgarvey 5y ago
This is an important point - developers have a tendency to focus on our individual performance rather than the performance of the entire organization. In my experience, while individual performance goes down for some with pair/mob programming, both quality and velocity go up for the whole organization. And it goes without saying that we developers love our freedom because it means we can work at our own pace. Often I find when I'm pairing all day I'm putting in way more focused time than when I am soloing.
- mbrodersen 5y ago
  Not my experience at all. All you need is one toxic/incompetent/stubborn developer to be part of your group and everything slows down to a crawl. Removing developers from a team can dramatically increase the productivity of the team.
mbrodersen 5y ago
Not my experience at all. Perhaps you simply worked with developers that were better than you? So your productivity seemed to improve because they took more of the load? No offence but it could be a possibility. In my experience, doing pair programming etc. is great fun but it most definitely slows me down. I constantly have to explain why it makes sense to do X and why individual steps work.

helen___keller 5y ago

Even if the instant velocity of some practice is higher, the long term average velocity might not be. Which is to say, if your devs hate pair or mob programming and quit, your teams velocity is going to be greatly impacted. If devs consistently react negatively to a practice, in itself that’s evidence to be wary of the practice.

TameAntelope 5y ago
Then you can hire devs who are better able to build the things that you need.
ryanbrunner 5y ago
If devs universally react negatively to a practice, sure. If some devs don't like a practice, but it's more effective, that's an argument to ensure that you're filtering for it in hiring.

ryanmcgarvey 5y ago

This is an important point - developers have a tendency to focus on our individual performance rather than the performance of the entire organization. In my experience, while individual performance goes down for some with pair/mob programming, both quality and velocity go up for the whole organization. And it goes without saying that we developers love our freedom because it means we can work at our own pace. Often I find when I'm pairing all day I'm putting in way more focused time than when I am soloing.

mbrodersen 5y ago
Not my experience at all. All you need is one toxic/incompetent/stubborn developer to be part of your group and everything slows down to a crawl. Removing developers from a team can dramatically increase the productivity of the team.

mbrodersen 5y ago

Not my experience at all. Perhaps you simply worked with developers that were better than you? So your productivity seemed to improve because they took more of the load? No offence but it could be a possibility. In my experience, doing pair programming etc. is great fun but it most definitely slows me down. I constantly have to explain why it makes sense to do X and why individual steps work.