I'm an agile coach and my clients won't stop talking about this. Here's the deal, some 70%+ of developers are introverts. Mobbing can be great for fixing a bug or mentoring more than one person at a time but mobbing is not how you should expect your devs to work all day every day. This is probably not lost on fellow HN'ers but OMG the cargo culting amongst managers. Do not let them see this article. Lastly, watch thi…
Oh, good lord, that looks awful. I'd be fidgeting around like the guy in the black shirt all day. The worst thing is it would just be exhausting. Having to constantly deal with people for eight hours straight, with no peace and quiet or private space to think would be maddening. I'd rather swing a chainsaw bucking up firewood on a hot day.
Mob Programming – The Good, the Bad and the Great
51–60 of 98 posts
Re: Mob Programming – The Good, the Bad and the Great
#52I have not had the chance yet to use mob programming on a real project. But I have used it when teaching workshops and trainings. And it worked pretty well. The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer…
I don't know about day-to-day or in a classroom setting though. Whenever I did pair programming in college, one of the partners would often be overpowering in terms of skills and intelligence, and would spend most of the time getting the other up to pace. Which is great, except the laggards would often pretend to understand in fear of being looked upon as stupid.
As someone who's been on both side of the dynamics, yeahh, not sure about classroom settings. I would love to attend your workshops though!
Re: Mob Programming – The Good, the Bad and the Great
#53Upvoting because it's a fascinating idea. I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Off the top of my head though, I'd be worried about: - No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets…
Hey! One of the authors here. I will do my best to provide some responses, but it's kind of late here. - I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Not at all the case, we had some bad but felt the post was kind of long so they ended up edit out. No one but us reviewed the post first ;) Actually didn't even really notice all the…
>> Constantly bringing people up to speed… > Not sure I follow this one :P
The point came from (as did all of them really) past experiences of mine. I've found it can be incredibly painful and time-consuming to expect 100% of people to understand 100% of situations. A few years and companies ago we got to the point where there was an entire day of planning for a 2 week sprint, due to this requirement for total understanding. It was not an enjoyable experience, and I still don't believe it was a worthwhile tradeoff.
I believe everyone should understand the whole project at a high level. However, I'm very comfortable with only understanding a portion of the software or features being currently developed at the deep level required to work on them at that instant. I'm happy to let go and trust that the people who do understand will do a good job without my input. I can always learn about it later if I have to, because while I don't have to know about everything, I also don't just know about anything (ie never completely silo).
But: I'm willing to accept that this is my impatience at play, and that everything would be better off if everyone understood everything. It's just been historically (for me) been a very large price to pay.
Re: Mob Programming – The Good, the Bad and the Great
#54Upvoting because it's a fascinating idea. I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Off the top of my head though, I'd be worried about: - No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets…
And maybe the cost? If you pay 5 developers, I wonder how much more (or less) they get done by working individually or by doing this mob programming.
I really wish we had hard data on this. But we did not have reliable metrics in place before. I would however argue that there isn't data the other way either ;)
But in lack of hard data, I can say what our gut feeling is. We started with mob programming because we felt we had a total inability to deliver anything (lots of half done work), and now we feel like we are delivery frequently with high quality.
Re: Mob Programming – The Good, the Bad and the Great
#55Re: Mob Programming – The Good, the Bad and the Great
#56Since you all have been asking, here's a negative excerpt from an earlier version of this post, which unfortunately got cut before the final draft. I'm starting to feel like we should write a follow up post now, but in the mean time, here's this:
"It was not all positive. Finding a smooth way of working took a long time, and we lost team members along the way, presumably at least partly because they did not enjoy this. Personality differences became painfully obvious, and a lot of time was spent talking openly and honestly to each other on how to stop rubbing each other the wrong way.
Taking on new people is both easier and harder in this setting. The bonus is that they will come up to speed with the work a lot sooner. The drawback is that you have to redo the personality resolution dance before work will run smoothly again."
My take on the introvert/extrovert thing:
I'm definitely one of the extroverts on the team (even though I, like introverts, get completely exhausted by too much interaction). I thrive in a communicative environment. We have a pretty fair mix of people on the team, and we've spent some time trying to find the balance of that, leaving room for people to leave the mob when needed etc. We usually do not mob for eight hours a day - reality hits, someone comes in early, someone likes to work late, we attend meetings, we are all parents and sometimes have to work from home, and we try to encourage each other to leave the mob at times. My guess is that we mob approximately 70% of the time. My impression is that our introverts, while finding it tiresome, are a lot more expressive and take up more social space in the group than before. The extroverts have worked hard on stepping back and leaving space. We still have ways to go, but we're getting there.
We are just one team in an organization of many teams working on different parts and features of the same system. We do not feel that we need to understand 100% of everything all the time, but our general knowledge has most definitely improved, and rapidly so. We all feel more comfortable around our own components than before.
Re: Mob Programming – The Good, the Bad and the Great
#57Earlier quoted context omitted.
Hey! One of the authors here. I will do my best to provide some responses, but it's kind of late here. - I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Not at all the case, we had some bad but felt the post was kind of long so they ended up edit out. No one but us reviewed the post first ;) Actually didn't even really notice all the…
Hey Zebra, thanks for the replies, IMO you should edit your blog post (or link to your comment here) because that's a really helpful set of counter experiences that make your blog post feel much more genuine, compelling and relatable. >> Constantly bringing people up to speed… > Not sure I follow this one :P The point came from (as did all of them really) past experiences of mine. I've found it can be incredibly pain…
I think the main point about "Constantly bringing people up to speed" is that this now happens without overhead, just sort of naturally, to the point that we don't even notice it.
Re: Mob Programming – The Good, the Bad and the Great
#58Mob programming because they don't trust the individual developers to deliver by themselves, mob programming because no one has a clue there and they hope there is wisdom in the crowd, and mob programming because they had nothing else to do.
Re: Mob Programming – The Good, the Bad and the Great
#59Upvoting because it's a fascinating idea. I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Off the top of my head though, I'd be worried about: - No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets…
I could imagine maybe this one could go either way, depending on the loudest personality type. Every team has a range of skill levels and styles, so there are inevitably people who skew towards more time writing code and less time thinking (as well as the opposite. Some middle ground is probably optimal).
A lot of these people might just never have really thought about and might not know any other way, and if the majority and/or loudest voice of the mob is more conservative about thinking through things before starting to code, it'll rub off on everyone else.
That said I do agree with your sentiment to some extent, I find I personally do better thinking on my own than in a group. Part of it is needing to go off in a ton of different directions and then consolidate the ideas afterwards, and in a group setting there's a pressure to talk through things aloud which dramatically slows this ability to branch out.
Re: Mob Programming – The Good, the Bad and the Great
#60Do you find problems with bridging background knowledge across roles?
For instance, you have programmers with 5+ years experience reading/writing code. They understand basic data-structures & design patterns through second-nature. Does this create conflict and/or dis-engagement between the programmers & the non-programmers (management, QA, etc)?
Typically, I work on teams with scarce technical employees. Most of the team are there offloading work that doesn't require the coding background.