Re: [extremeprogramming] Pairing styles

"Jeff Langr" <[email protected]> Tue, 29 Oct 2019 16:19:54 -0600
Newsgroups gmane.comp.programming.extreme-programming
Message-ID <[email protected]>
Joshua Kerievsky wrote on 10/29/19 11:23 AM:
> On Tue, Oct 29, 2019 at 10:19 AM Jeff Langr <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     I see sometimes near-violent reactions to pairing from devs.
>
>
> Ward used to encounter resistance to pairing and it usually stemmed 
> from people not knowing what pairing was. So he'd invite them to pair 
> and afterwards they'd say things like "oh, I didn't know this is what 
> it was - I like this!"

+1. We (programmers) have a somewhat natural bit of pride (arrogance?) 
that leads us to believe we're smart enough to figure out everything on 
our own.

Pairing is a simple concept, but like much of agile, TDD, life, 
whatever, there are so many ways to practice it in a manner that rubs 
participants the wrong way. Usually you can figure out what's causing 
the sore spots, but some corrections require non-obvious insights / 
perspectives.

For example, I'm convinced that a large part of the reason the mobbing 
sessions I'm in have been successful is due to use of strong-style 
pairing. Another big reason is putting the rotations on a short timer 
(5-8 minutes). Both ideas (neither mine) keep people engaged, minimize 
the potential for dominance, and shrink the fear of being on point as 
the driver. In all teams I've engaged with who had already been mobbing, 
they hadn't dreamed up these tactics for improving the mob (some had 
adopted the tactics after hearing about them from other teams). The 
teams who adopted these non-obvious ideas generally stuck with them, 
claiming they were more effective and enjoyed mobbing more.

With pairing, sometimes it's as simple as figuring out how to get the 
keyboard consistently moving back and forth (ping pong, usually), and 
rotating the pairs more frequently.

Coaching is one remedy. Bringing in external observers who can 
demonstrate better practice, and who know how to spot wheel-spinning 
(and what appropriate corrections to recommend), is absolutely worth it. 
Sensible pros in other fields pay well for it.

Reading a lot & listening is another remedy. Sometimes we're not good at 
believing the things others have found success with (e.g. the use of 
strong-style pairing... or even the preference for mobbing over 
pairing). When multiple teams tell me "we're going faster," I believe 
them. And if I'm not seeing it with my team, I'm presuming we're doing 
something poorly.

Jeff

<http://langrsoft.com> 	
Jeff Langr/ Langr Software Solutions, Inc. <https://twitter.com/jlangr> 
<https://www.linkedin.com/in/jefflangr> 
<https://www.facebook.com/jeff.langr>
http://langrsoft.com +1-719-287-4335
Pragmatic Unit Testing in Java <http://pragprog.com/book/utj2>
Modern C++ Programming with TDD <http://pragprog.com/book/lotdd>
Agile in a Flash <http://pragprog.com/book/olag>
Agile Java: Crafting Code with Test-Driven Development 
<http://amzn.com/0131482394>
Essential Java Style <http://amzn.com/0130850861>


	








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160146): https://groups.io/g/extremeprogramming/message/160146
Mute This Topic: https://groups.io/mt/39413621/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-