found drama

A couple weeks ago, I finished reading Shore and Warden’s The Art of Agile Development as part of a (half-hearted? abandoned?) book club/reading group. Our goal was to get familiar with Agile’s core tenets and terms, ¹ to become adept at speaking about it, and to allow that knowledge to guide us as Agile practitioners and ambassadors. As I progressed through the book, a sense of foreboding itched at me–something about their discussion of Agile unnerved me. ² Eventually, it came to me: “eXtreme Programming” (a.k.a., “XP”, Shore and Warden’s espoused flavor of Agile)–with its perpetual pair programming, and open concept bullpens, and continuous collaboration–sounded an awful lot like the fundamentally flawed “brainstorming and teamwork” of the “New GroupThink” that Susan Cain wrote about in her book, Quiet. ³ If you’re unfamiliar with Quiet, or with Susan Cain, her gist was this: “brainstorming” and group work effectively shut down and tune out introverts, and the empirical evidence suggests that these methods also produce results that are worse than the alternatives.

But, I insisted to myself, Agile is solving a real problem! How was I to reconcile this paradox?

The Agile Paradox

My practical experience with Agile has been positive. Having short iterations forces you to focus on only a handful of specific, achievable, and deliverable items at a time. Committing to only a couple of specific deliverables forces everyone to have the kinds of conversations that reveal real priorities. Understanding the real priority of something to someone helps you to understand its real value, and thus underscores the importance of the committment you made to deliver it. And making good on those committments builds trust. When all of these parts of the cycle are working, it is very satisfying–and the satisfaction comes from knowing that the system is effective. That you are effective.

But my academic knowledge of Agile ⁴ is what leaves me cringing. It’s that academic knowledge where we see Agile’s cliches: pair programming, bullpens, stand-ups, and scrums. We talk about close collaboration, about embedded customers, about test driven development, and about continuous integration. If you follow Shore and Warden’s advice, you’re using all of these techniques (and others)–and if you’re not using them all (and exactly as described), then you’re not Agile. ^{5 6} Granted, the goals of adopting Agile are goals that everyone ought to be able to get behind: to avoid thrash and fractional assignment, and to work on and deliver only the most valuable features. Surely these annoyances are a small price to pay for being effective and successful. Who wouldn’t want to use such a system?

Well… introverts.

Agile Alienates Introverts

I’ve come to believe that Agile/XP, with its emphasis on “continuous collaboration”, favors extroverts to such an extent that it becomes trivial to marginalize introverts, and thus it is implicitly damaging to introverts. This is my thesis.

But first, you may be asking: Who are introverts? What does that even mean? Susan Cain defined introversion like this: ⁷

It’s how you respond to stimulation, including social stimulation. So introverts prefer lower-stimulation environments, that’s where they feel at their most alive. Whereas extroverts really crave stimulation in order to feel at their best. It’s important to see it this way because people often equate introversion with being antisocial, and it’s not that at all–it’s just a preference.

In other words: people that burn out quickly when their environments demand continuous social interactions. These are not necessarily shy people ⁸–but they are people who are not going to cope well with 40+ hours of pair programming, stand-up scrums, and iteration demos every week.

It is important to note that I recognize a conflict here. These activities, these methods and systems are effectively the “pillars” of Agile. We could split some fine hairs here depending on which flavor of Agile you happen to be practicing, but that’s the meat of it. You put everyone in continuous close contact, shake well, and (theoretically) you get to pour out a delicious cocktail of productivity and effectiveness and developer ⁹ happiness. And there is a kernel of anecdotal truth to that: the close contact can enable truly “high-bandwidth communication” that permits valuable and meaningful conversations. But these very same arrangements can be aversive (or even hostile) to introverts. An introvert has the same need for “high-bandwidth communication” as an extrovert; the difference is that when the conversation is over, the introvert needs to withdraw in order to process the conversation, ¹⁰ to act on it, and to recover for the next one.

Both of these cognitive styles are completely valid. Introversion doesn’t make you smarter, just as extroversion doesn’t make you dumber. They’re just different styles. And yet Agile has constructed an environment where being an introvert puts you at a disadvantage. ¹¹

The Collaboration Conflict

When I was reading The Art of Agile Development, this conflict hit home for me while reading the “Sit Together” section in the “Collaboration” chapter. You get the sense that Shore and Warden believe this to be the foundational principle of Agile/XP; they say that in order to become a highly-effective Agile team, you must have the kind of high-bandwidth communication that you can only get from sitting side-by-side and from talking face-to-face. At first glance this is easy to agree with; if you’ve ever misinterpretted an email only to clear up the confusion with a two-minute conversation, then you have all the anecdotal evidence you’ll ever need. But Agile/XP goes too far with this. Everyone sits side-by-side; everyone is within earshot of everyone else; everyone interrupts each other constantly; ¹² no one works alone on anything. Ever. For any reason.

This thought terrified me. There has got to be room for both, I thought. Which (I’ll admit) is a hard thing to admit as an introvert: that you recognize the value that “continuous collaboration” brings, and that you (gasp!) might even want it. Only… maybe you don’t want your “continuous collaboration” to be… quite so continuous.

So what’s an introvert to do?

“Thunderdoming” and “Hunkering Down”

First, the bad uncomfortable news: Sometimes there is absolutely no substitute for a good ol’ fashioned Agile bullpen. You’ll be better off if you accept this now. While (as an introvert) this is usually the last thing on Earth that I want to do, there are situations that demand it. If you’re up against an important deadline delivery, then you know that you need all the communication bandwidth you can get. Sometimes it’s easier to just have everyone in a room, stand up, shout out the latest critical changes, kick off the integration build, and move on to the next thing. (Where I come from, we call this “Thunderdoming.”)

Contrarily, as an introvert, you already know that “Thunderdoming” in a bullpen like that will just wear you down and burn you out. You can do it (I know that you can) and sometimes you’ll need to do it (I know you’ll recognize those moments when they come) but you’ve also got to stand up and tell your Project Manager or Scrum Master or whoever that sometimes you need to withdraw and hunker down. Remember, they won’t know this about you–you’ll need to tell them. Don’t be shy, ¹³ just tell them: I am an introvert, and if you want me to be maximally effective then you need to let me hunker down.

That’s how I like to think of it: as “hunkering down”. But an introvert’s style of “hunkering down” does not, on the surface, mesh well with the espoused systems that propel Agile/XP. As I read through Shore and Warden’s The Art of Agile Development, I did not see a single place where they acknowledged this or discussed how one might deal with introverts on the team. In Team Geek, ¹⁴ authors Brian W. Fitzpatrick and Ben Collins-Sussman also emphasize the importance of this kind of collaboration, but they also acknowledge that the team might have (“serious”) introverts; sadly, their footnote on this offers no real strategies:

We do however acknowledge that serious introverts likely need more peace, quiet, and alone time than most people and may benefit from a more quiet environment if not their own office.

So… at least we’re on the radar, but the statement seems like an arm’s-length coddling. “Peace, quiet, and alone time”? Come on! We’re adults, we can take it; we’re not asking for things to be easy, we’re just asking that you stop talking so damn much.

When I think about what it means to “hunker down”, I think about what Susan Cain wrote in Quiet. First, introverts are going to be less effective in a bullpen, or really anywhere that has lots of talking and interruptions and stimuli. ¹⁵ (Cain talks pretty extensively about this sort of thing in Quiet.) So what do introverts really need? How do we meet these mutually exclusive goals? How can introverts reap the benefits of Agile without having it destroy them in the process? How do we have the kind of close collaboration that we know produces the best results, while still giving introverts the social distance necessary for them to think and work effectively?

An Introvert’s Survival Guide to Agile

As with everything else, it is a delicate balancing act. Fortunately, in this case, it comes down to three basic rules:

1. Just say “no” to pair programming. Seriously. If you’re an introvert, don’t do it. Don’t allow yourself to be pressured or cajoled or bullied into it. You won’t be able to think straight with someone else at your ear every minute. However, that doesn’t mean you get to work in a vacuum. If you’re eschewing pair programming, it is now your responsibility to do many small and focused code reviews. (Seriously: do at least two every day.) You’ll lose the (alleged) benefits of actual pair programming, but as an introvert, you probably weren’t benefitting all that much anyway.
2. “Early” is the time for close collaboration. I mean “early” in a couple of different senses here. First, if you’re new to a team or a project, try to suck it up and do as much “close collaboration” as you can. In those critical early stages, that is when you (yes, even you) are going to need the most contact–you’ll even need the interruptions. Those early stages are when the shared nomenclature is being established, and when the foundational decisions are being made about design and style and architecture, and all that other good stuff. ¹⁶ Once the project is established though, “early” (as in “in the morning”) is when you want to do your close collaboration. It’s the morning, so you should be fresh, and it should be easier for you to absorb the strain that the social interactions put on you; everyone else should be fresh too, which makes it a good time to get a sense of what happened the day before, and to let that guide you on what to do today. (Side note: if the team’s Project Manager/Scrum Master is amenable to it, consider having the stand-up/scrum earlier rather than later in the day. If it seems like blasphemy, then it’s the right thing to do.)
3. “Withdraw” and hunker down only when you have a plan for your work. This may seem intuitive, but it’s worth codifying as a rule because it sets limits and boundaries around the “alone time” and makes it seem “more fair” to the extrovert contingent. As introverts, you and I both know that “withdrawing” to hunker down is how we get “real work” done. But, you better have a list; you better know exactly what you’re going to work on in that block of time, and you better accomplish it. Remember, Agile is about being effective and productive, but it’s also about creating trust through transparency. If you have withdrawn to your little corner or office or whatever… Well, no one can see you, can they? They won’t know what you were working on, nor will they know when you’re having trouble. The way to handle this is to look at Rule #2 as the price you pay to have Rule #3, so that you can continue to reap the benefits of Rule #1. If you are “socializing” effectively, then you will gotten the necessary information from your conversations. You use that information to get everything “straight enough” so that when you disengage, you already have a plan to work on “this, this, this, and this”. (Think of them as self-contained and personalized “pico-iterations”.) The catch is: seek help immediately when you get stuck. ¹⁷ That is the hard part; that is the trade-off: you get to hunker down, but you must orbit back to the group for support.

I believe that those three basic rules create a kind of “Survival Guide” for introverts in an Agile environment. There are a lot of challenges to which Agile provides good solutions, but it is hard to look at its surface and see an “introvert-friendly” system. However, with a little creative maneuvering, Agile can be made to work for introverts just as well as it works for extroverts.

1. If you’ve never heard of Agile software development before, the Wikipedia article is actually pretty good. (Link.)[↩]
2. I need to be up-front here: I do not ding Shore and Warden for my “unnerved” feelings re Agile; my statements should not be interpreted as a knock against their book. If anything, I am eager to recommend The Art of Agile Development to anyone looking for a decent title on the subject. While I would not exactly call it enjoyable (the tone is too dogmatic for that), they present a comprehensive (if not exhaustive) and easily digestible discussion of Agile in which they put serious effort into factoring in real-world constraints and considerations.[↩]
3. Here is my March 2012 review of Quiet. It’s a fascinating read regardless of where you land on the introvert/extrovert spectrum.[↩]
4. Again: that “academic knowledge” is based largely from Shore and Warden’s The Art of Agile Development, but also from articles like this one about “Agile fluency” and blog posts like this one about pair programming.[↩]
5. As I said before, Shore and Warden are dogmatic about this. They admit it right there in the text. They urge you to adopt all of these practices and to follow them rather rigidly, to gain some “fluency” before deciding how to slice-and-dice. I bristled at this more than a little bit, especially since they spend at least half-a-page in each section talking about “contraindications” and about how to deal with real-world friction caused by their recommendations. I understand why they make the recommendations that they do, I just happen to find it… less than flexible, and thus unaccommodating. In other words, too rigid to be practical.[↩]
6. And don’t tell me about how such a rigid system is basically subject to lampooning itself, that anyone that takes on such a rigid system is “missing the point”. I think we can all agree on that, and even the name (Agile!) underscores how important it is to be flexible and to pivot quickly etc.–but we still must acknowledge the fact that there are plenty of authoritative sources and mentors out there making dogmatic statements like this.[↩]
7. The definition comes from Ian Tucker’s interview of Susan Cain for The Guardian. (Source.)[↩]
8. Susan Cain makes a point of drawing a distinction between introversion and shyness. When Gareth Cook interviewed her for Scientific American, she told him: “Shyness is the fear of negative judgment, while introversion is simply the preference for less stimulation. Shyness is inherently uncomfortable; introversion is not.” (Source.)[↩]
9. I’m using “developer” loosely here. Fill in that blank with whatever job role you happen to want to fill it with. After all, doesn’t Agile make everyone a “developer”?[↩]
10. I feel the need to call out this point in particular because it is something that I (as an introvert) always took for granted. I always assumed that everyone needed to do this, to find a quiet place to review your notes (mental or otherwise), to think through what they mean, and to decide what you’re to do with that knowledge. Over the past few years though, I’ve noticed that extroverts don’t work this way; they tend to think out loud. A conversation ends but–rather than quietly reflect on it–they keep talking, making sense of the conversation by reviewing it or talking through hypotheticals, etc. When I first realized this about extroverts, I was horrified; now I just find it fascinating that someone might need to do that–literally hear himself think.[↩]
11. Or at the very least: an environment that is disproportionately more taxing on you than it is on your peers.[↩]
12. I wouldn’t even call this an exaggeration; The Art of Agile Development contains the following statement:

    Many organizations discourage interruptions, but I encourage them on my XP teams.

    Shore and Warden talk about creating flow, and about respecting someone when she doesn’t respond to you (i.e., recognizing that she is cranking on something, and so you better hold your horses for a minute)–but it’s undeniable that the whole concept of bullpens and pair programming is to encourage interruptions in the name of communication.[↩]

13. Remember what Susan Cain said about the difference between being an introvert and being shy?[↩]
14. Here is my July 2012 review of Team Geek. I’ve been recommending it to pretty much everyone that works in software engineering.[↩]
15. I have a distinct memory of one particular “Thunderdome” where I was so overwhelmed that I was almost physically ill. We had just finished our stand-up and people had broken off into twos and threes to wrap up a few of the conversational loose ends. It was like my brain tried to listen to every conversation at once. And then when two people asked me questions at the same time, I put my hands over my ears and left the room. It was the only way to stay sane.[↩]
16. If the project is already under way and you’re a late-comer, then the rule still applies; it’s just that now you’re playing catch-up instead of participating in those foundational discussions.[↩]
17. Your version of “stuck” may not be the same as an extrovert’s, and that’s okay. They’ll come up and start tapping shoulders more/less immediately. (Remember, they think out loud anyway.) You’re going to poke and prod at it and do searches on Google or Stack Overflow first. And contrary to what some “experts” might say: this is just fine because this is how you need to think about the problem.[↩]

About Rob Friesel

23 Responses to Agile for the Introvert