recentpopularlog in

kme : pairing   9

Diverse Teams Feel Less Comfortable — and That’s Why They Perform Better | https://hbr.org/
Via: "To Pair or Not to Pair: Pair Programming" - https://www.youtube.com/watch?v=u_eZ-ae2FY8
With so much at stake, why aren’t these companies making more headway? One reason could be that, despite the evidence about their results, homogenous teams just feel more effective. In addition, people believe that diverse teams breed greater conflict than they actually do. Bringing these biases to light may enable ways to combat them.
After collectively naming their suspect, members individually rated aspects of the discussion. More diverse groups — those joined by someone from outside their own fraternity or sorority — judged the team interactions to be less effective than did groups joined by insiders. They were also less confident in their final decisions.

Intuitively, this makes sense: On a homogenous team, people readily understand each other and collaboration flows smoothly, giving the sensation of progress. Dealing with outsiders causes friction, which feels counterproductive.

But in this case their judgments were starkly wrong. Among groups where all three original members didn’t already know the correct answer, adding an outsider versus an insider actually doubled their chance of arriving at the correct solution, from 29% to 60%. The work felt harder, but the outcomes were better.

In fact, working on diverse teams produces better outcomes precisely because it’s harder.
This idea goes against many people’s intuitions. There’s a common bias that psychologists call the fluency heuristic: We prefer information that is processed more easily, or fluently, judging it to be truer or more beautiful. The effect partially explains that we gain greater appreciation of songs or paintings when they become familiar because they’re more easily processed. The fluency heuristic leads many people to study incorrectly; they often simply reread the material. The information becomes more familiar without much effort, and so they feel that they’re learning. But in a 2011 study students performed better on a test after studying the text once and then trying to recall as much as they could, a strenuous task, than they did by repeatedly going over the text, even though they predicted that rereading was the key to learning. Similarly, confronting opinions you disagree with might not seem like the quickest path to getting things done, but working in groups can be like studying (or exercising): no pain, no gain.
In one study MBA students were asked to imagine that they were comanaging several four-person teams of interns, and that one team had asked for additional resources. They saw photos of the members, depicting four white men, four black men, or two of each. They then read a transcript of a discussion among the group and rated the team on various factors. Teams of four white men and four black men were seen as having equal levels of relationship conflict, but the diverse teams were seen as having more relationship conflict than the homogeneous teams, even though everyone had read the same transcript.
For example, research suggests that when people with different perspectives are brought together, people may seek to gloss over those differences in the interest of group harmony — when, in fact, differences should actually be taken seriously and highlighted. In a 2012 study teams of three were tasked with generating a creative business plan for a theater. On some teams, members were assigned distinct roles (Artistic, Event, and Finance Manager), thus increasing diversity of viewpoints. These teams came up with better ideas than homogeneous teams — but only if they’d been explicitly told to try to take the perspectives of their teammates. They had to face up to their differences in order to benefit from them.
Another way to take advantage of differing viewpoints is to highlight the value of multiculturalism. One 2009 study looked at support for multiculturalism versus colorblindness in nearly 4,000 employees in 18 work units at a large U.S. health care firm. The more that workers agreed that “employees should recognize and celebrate racial and ethnic differences” and the more they disagreed that “employees should downplay their racial and ethnic differences,” the more that minorities in those units reported feeling engaged in their work. In another 2009 study, pairs of students, one white and one Aboriginal Canadian, were teamed up for a conversation. Prefacing the meeting with a message supporting multiculturalism (versus no message) made the meeting more positive, while a message endorsing colorblindness led whites to turn negative toward their minority partners.
teamwork  diversity  cognitivebias  bias  pairing  pairprogramming  groupthink  fluencyheuristic  nopainnogain  multiculturalism 
december 2018 by kme
The Shame of Pair Programming | Diary of a ScrumMaster | https://diaryofascrummaster.wordpress.com/
To pair requires vulnerability. It means sharing all that you know and all that you don’t know. This is hard for us. Programmers are supposed to be smart, really-crazy-smart. Most people look at what we do and say “I could never do that.” It makes us feel a bit special, gives us a sense of pride and pride creates invulnerability. I often hear stories that infer “I’ll just go and do some magic and if it takes a long time you can bet I made miracles happen”.

When done well, the shame of pairing quickly evaporates. As you start to realise that, between the stuff you know and the stuff they know, you can be twice as good; pairing becomes joyous. Together we find solutions that would be out of reach if we were alone.

Also, a shout-out to Brené Brown:
It’s hard. Pairing well takes empathy, empathy evaporates shame, allowing courage. As Brené Brown says “Vulnerability is the birthplace of Innovation, Creativity and Change”
pairing  pride  collaboration  devel  programming  pairprogramming  vulnerability 
december 2018 by kme
To Pair or Not to Pair: Pair Programming - YouTube | https://www.youtube.com/
Lady's from ThoughtWorks (https://www.thoughtworks.com/), and if that's sounds familiar, that's because they're the Selenium and GoCD people.

Benefits mentioned in the video:
1. knowledge sharing (1 + 1 > 2)
2. combines two modes of thinking: tactical (driver: local optimization), strategic (navigator: big picture)
3. reflection (on the story, value-added, effectiveness vs. # of LOC)
4. helps coder / team focus; discipline around structure of code, strategy, explain and justify choices, avoid rabbit holes
5. "I get more programming productivity" out of reducing time that I'm stuck than from increasing my speed when I'm not stuck."
6. helps practice "true" CI--code review on-the-go; more collective code ownership; >> trunk-based development

Tips:
1. don't do it for 8 hours a day
2. take breaks; it's exhausting
3. even skill levels
4. share feedback (I don't like it when ...), exchange READMEs
5. "the shame of pair programming"; requires vulnerability

Homogeneous teams feel easier, but easy is bad for performance. (ref: https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better)

The authors are saying that this idea goes against many people's intuition, and often if there's something counter-intuitive, there's a cognitive bias hidden away somewhere, right?

And the one that they're mentioning here is the "fluency heuristic," which says that we prefer information that is more easily processed, and if it's easily-processed, we think that it's more true, more right, more beautiful, and that serves us very well in a lot of situations in software development. We want readable code, easily-processable things. But I don't think that it serves us well if we think that's why we're not doing pair programming.

So, pairing feels hard, but that doesn't mean that it's not good for performance, and also it doesn't have to stay hard.

Ways to make it easier (reduce friction, conflict, anxiety):
1. get the talking going
2. active listening
3. friendly feedback
4. answer why

See also: https://www.youtube.com/watch?v=S92vVAEofes
agile  cs  programming  pairing  pairprogramming  teamwork  collaboration  communication  conference  talk  video 
december 2018 by kme

Copy this bookmark:





to read