Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Is Agile Stifling Introverts?

Is Agile Stifling Introverts?

Leia em Português

This item in japanese

Lire ce contenu en français


For years Agile has been encouraging teams to work together collaboratively in open spaces and encouraging developers to pair program, but lately these types of practices have been coming under fire.

Back in January, The New Yorker published a piece on brain storming called Groupthink.

Brainstorming seems like an ideal technique, a feel-good way to boost productivity. But there is a problem with brainstorming. It doesn’t work.

Citing various studies the article concludes:

Brainstorming didn’t unleash the potential of the group, but rather made each individual less creative. Although the findings did nothing to hurt brainstorming’s popularity, numerous follow-up studies have come to the same conclusion. Keith Sawyer, a psychologist at Washington University, has summarized the science: "Decades of research have consistently shown that brainstorming groups think of far fewer ideas than the same number of people who work alone and later pool their ideas."

Of course, brainstorming is not an integral Agile technique and may not be used at all in many Agile teams, but what about team rooms, group-work, and pair programming?

Susan Cain, recently gave a very popular TED Talk titled, The Power of Introverts". Her talk and the accompanying blog post took aim at our bias for extroverts and group-work:

Solitude, as Cain says, is a key to creativity. Darwin took long walks in the woods and turned down dinner invitations, Dr. Seuss wrote alone, and was afraid of meeting the kids who read his books for fear they would be disappointed at how quiet he was. Steve Wozniak claimed he never would have become such an expert if he left the house. Of course, collaboration is good (witness Woz and Steve Jobs), but there is a transcendent power of solitude.

And the things we’re learning from psychology affirm this. We can’t be in a group of people without instinctively mirroring each other, and groups follow the most charistmatic person, even though there is no correlation between being a good speaker and having great ideas. (Hesitant, then full laughter from the TED crowd.)

She closes her to talk with a call to action:

"End the madness of constant group-work." (The audience applauds.) Offices need chatty conversations, and great spaces to make serendipitous interactions. But we need much more privacy, and more autonomy. The same is true - more true - for schools. Yes, teach kids to work together, but also how to work alone.

In a sign that she’s right that change is coming, almost the entire auditorium, introvert and extrovert alike rises to give a standing ovation.

Jon Evans wrote about office spaces and pair programming recently in his Tech Crunch article: Pair Programming Considered Harmful?

Legendary development shops like San Francisco’s Pivotal Labs and Toronto’s Xtreme Labs(1) have adopted a 100 percent pair programming mindset, with considerable success.

Great! Problem solved, right?

…Not so fast.

"Research strongly suggests that people are more creative when they enjoy privacy and freedom from interruption ... What distinguished programmers at the top-performing companies wasn’t greater experience or better pay. It was how much privacy, personal workspace and freedom from interruption they enjoyed," says a New York Times article castigating "the new groupthink." It also quotes Steve Wozniak:

"Work alone… Not on a committee. Not on a team."

Open-plan offices, in particular, seem an impressively terrible idea. "Open plan layouts create massive distraction, damaging productivity," according to a recent analysis by the U.K.’s Channel 4. See also the related Hacker News commentary, which includes gems like "Most modern office layouts seem to be designed to screw with people's fight or flight instincts all day," and "I'm a quiet type, and I often need time alone to think and write code and documentation. The 'rah rah' social types railroaded us ... I am becoming bitter and resentful."

Jon also sums up evidence that pairing can be good for creativity:

Working alone is good for creativity - but being paired with someone who thinks differently from you can lead to more creativity yet.

And concludes:

The true answer is that there is no one answer; that what works best is a dynamic combination of solitary, pair, and group work, depending on the context, using your best judgement. Paired programming definitely has its place. (Betteridge’s Law strikes again!) In some cases that place may even be “much of most days.” But insisting on 100 percent pairing is mindless dogma, and like all mindless dogma, ultimately counterproductive.

Another article addressing how social media caters to extroverts, blames the tech companies behind social media:

Blame Mark Zuckerberg. When Facebook went public at the beginning of February, its doe-eyed CEO released a letter to investors describing it not as a company, but as some sort of religious sect, which would make Zuckerberg, its leader, a kind of social missionary. Facebook, he wrote, "was built to accomplish a social mission—to make the world more open and connected."

Zuckerberg famously champions workplaces with open floor plans and glass walls as a metaphor for the world as he dreams it. This is one example of how the free-for-all nature of social media is seeping into real life-and it’s a problem for those of us who liked the walls where they were.

I guess there aren’t many introverts working at Facebook.

Is Agile to blame for popularizing some of these ideas? Has Agile been stifling introverts and creativity all these years? If so, then what? Is it time to go back to the cubicles?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • An office with a door

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The need for focus and uninterrupted thought has always been important in software development. It's been known for a long time that giving engineers an office with a door on it improves productivity. (See Peopleware by DeMarco and Lister for example.)

    The worst environment I've worked in was an open room with 7 developers in it. It was very hard to get anything done. It was cheap for the company to set up, but very unproductive.

  • The resonance of a capable team, or the diversity of opinion?

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have to say, I agree with Dean to an extent. Certainly the concept of an engineer with a door works for quite a lot of people.

    Also, creativity is a wholly separate yardstick to personality and it can be present in areas which are not traditionally associated with a popular perception of creativity.

    However, controversially perhaps, a lot of agile proponents are really more like craftspeople than engineers. Indeed, there is a strong movement here in the UK towards craftsmanship and it certainly can’t be classes in the same rigorous domain as true engineering.

    The thing that probably defines whether or not the individual will be stifled by this is their personality. On example measure, the Myers-Briggs scale, focused quite heavily on introversion and extroversion in combination with three other dimensions and it is often seen that particular types of individual (the INTP and INTJ types) tend to be much more scientifically minded and have a greater predisposition to engineering and unconventional thinking. According to Wiki, Charles Darwin, who was mentioned in the above, is regarded as having been an INTP, together with Thomas Jefferson and Albert Einstein and they are inherently introverts.

    Pairing will require two individuals possessing the same key dimensions pertinent to the role AND the technical skillset to ‘resonate’ to get a better creative result. However, what sometimes ensues is a categorical waste as an individual may choose to back down or not challenge the more charismatic and skilled individual they are pairing with. Often resulting in code which the introvert was very sure would be inadequate, but didn’t have the ‘social standing’ to assert. We all know an introverted technical individual who was so above the technical leagues of others that pairing with them was be a futile exercise, because you simply couldn’t get what they were doing and the constant questioning of that individual when you have nothing to add slows them down, wasting the resources of both of the pair.

    However, those metaphorical ‘super-humans’ can’t do it on their own, simply because of the amount of work in enterprises these days.

    Here I the UK, the number of developers of that caliber is incredibly low. So the likelihood of finding individuals who are alike enough and with the same level of skill is low. This means you have to do agile with the teams you have and this will most likely exclude both the super smart and the not so smart from the productive range. In any case, a capable team is much more than the sum of its parts, it is just trying to cultivate the proverbial first rate team not a team of first-raters.

  • Re: The resonance of a capable team, or the diversity of opinion?

    by Dean Schulze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The idea of resonance is important.

    Pair programming depends a great deal on the individuals. I've know programmers who no one wants to work with. We were all very glad that they kept to themselves. I've also know programmers that I would enjoy pair programming with and would probably form a very productive team with.

    The XP geniuses pretend that everyone should pair program, unfortunately.

  • Why are we creating software?

    by Horia Slușanschi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It pays to remind ourselves why we create software in the first place. We don't do it just to optimize the way in which developers are conducting their work. We do it primarily to delight customers. To understand their needs (sometimes even before they realize them themselves), and to give them valuable features that provide satisfaction.

    This focus on value to the customer may require some "sacrifices". It requires collaboration & invention. Sometimes we can solve some problems in isolation, to the relief of introverts. However, we must mistake-proof our code-creation process, so various forms of verification have been devised - like pair work, reviews, inspections, automated testing, etc. There are benefits and drawbacks to each.

    In my opinion, it's more important to be able (and willing) to adapt your habits over time than to attempt to find a "perfect" structure or approach. Use common rooms when the Teams are best served by that structure. Provide retreat rooms to allow for uninterrupted focus and flow. Seek a balance that works for your specific situation, then inspect and adapt to maintain optimum results - with delight for customers and joy in work for people.

  • I always thought agile stuff was designed for introverts

    by jonny cundall,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As someone who would definitely consider themselves to be an introvert, I'm very positive about agile methods. I have worked in scrum, and am changing jobs soon just to get back into that environment.

    There are lots of examples where the meetings are set up to help people express themselves who would otherwise have difficulties. I'd much rather bring up impediments in a standup, where everyone takes their turn, than have to shout over people's desks or send some terrible group email. And retrospectives, which for me are the absolute cornerstone of any agile process, when done right are specifically designed to prevent them being railroaded by the dominant, extrovert personalities in the group.

  • What was it again that Brooks said?

    by Wilfred Springer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think I overheard him saying it at OOPSLA, years and years ago. It must have been something like this:

    There is no substitute for the dreariness of labor and the loneliness of thought.

    He must have borrowed part of that from Bernard Brauch, but I think I like it better this way. You need time alone for conceptual integrity, and interaction with fellow programmers to prevent premature optimization.

  • Re: I always thought agile stuff was designed for introverts

    by Amin El-assaad,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would like to agree with your statement johnny,

    I am an introvert as well and I have found a tremendous comfort inn using agile methodology. Probably a balance is required in everything we do. There must be a consIderatIon to the number of Introverts and extroverts In a team intreverts would need that extra amount of attention and continuous trust from their managers to promote them and be an active members of the team so we can enjoy their special qualities for a wonderful output

  • I agree!

    by raj n,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The worst thing to do is make it dogmatic. I read somewhere "I liked agile before it became KNOWN as agile". A related good read is also there somewhere on JoelOnSoftware.

  • There are a lot of good and valid comments here.

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    However, let’s not forget, the idea of introversion and extroversion is not a ‘habit’ per se, as after about the mid-twenties, particular personality traits become much harder to change (there is a physiological reason for this). Those people who have a predisposition to liking to be part of a successful team will thrive if the team is successful in agile or more structured approaches, so it makes no odds in that respect. Agile just makes those wins quicker for the customer, which makes the ‘feel good’ factor more regular for the individuals involved. Note, this is not a bad thing at all and if habits that are not tied to the inherent way people think are require to change to do this, then I am all for it. However, as we have seen with the demise of much more rigorous processes, this doesn’t always happen at all.
    Amin is right. Given particular job roles in a wider team, particular personality types are required in different job roles. Aside from the hard skills, the assertive personalities are for business interactions, leaders for program and product management etc. Remember, those extroverts can sell certain ideas to business that will get you the buy in to ‘do’ agile in the first place. You wouldn’t be able to get all round criticality (for those who know about De Bono’s hats) when assessing ideas without the emphasis that certain types of personality place on these particular ‘colours of thought’.
    As for premature optimisation, this is where I don’t fully agree with the way agile is conducted a lot of the time. There are certain things that you can see are going to cause problems way before they happen. You can often mitigate these risks by ‘defensive programming’ techniques to stop it before it becomes an issue. So, in the case of, say performance, if you now it takes 20 minutes to do something optimally, but 10 minutes to do it ‘agile’ but certainly will cost you two hours once the system is further down the line (for whatever reason), I would rather choose to spend the 20 minutes as the agile method could potentially introduced a much bigger amount of waste (which is counter to the lean principles that quite rightly seem to go in tandem). Pragmatism again.
    Early testing is good, thumbs up. Automated testing is good, thumbs up etc. But none of these are actually exclusively ‘agile’, so I would echo raj n’s reference because all agile did was change the focus to these best practise routines when unfortunately, devs in ye olden days refused to work the process as it was always seen as bureaucratic because it didn’t involve writing code immediately.
    But that is another argument for another thread I am sure.

  • Susan Cain and the wrong question

    by Mark Levison,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are many flaws with Susan Cains book. I've commented on the flaws: as has Keith Sawyer:

    But the deeper issue that many are missing is the focus. Agile doesn't optimize for the output of a single individual. Agile optimizes for the output of a team, what matters is how well we work together and whether we produce a great product. Not whether the individual is more productive.

    Mark Levison
    Certified Scrum Trainer | Agile Pain Relief Consulting

  • Re: Susan Cain and the wrong question

    by Ke Wa,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Actually, Mark, it looks like semantics - what you call group think (people listening to the ideas of others and granting them space and support) is the introvert leader who listens to team members. Susan Cain agrees with you. In her book "Quiet", the chapter "The Myth of Charismatic Leadership" describes how extroverts are more effective leaders of teams where the members are passive (not engaged) because they initiate action. But introverts are more effective leaders of teams where the members are engaged because introverts are much more likely to listen to and support team member ideas. The rebuttal you mentioned which describes the president of Georgia (where they don't prize extroverts as the USA does) is actually in full agreement with the research Susan Cain describes in her book. Mikheil had an engaged team and he listened to their ideas.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p