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,1 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.2 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.3 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 Agile4 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.56 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?
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:7
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 people8–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 developer9 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,10 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.11
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;12 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”
bad 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 , 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,13 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,14 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.15 (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:
- 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.
- “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.16 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.)
- “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.17 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.
- If you’ve never heard of Agile software development before, the Wikipedia article is actually pretty good. (Link.) [↩]
- 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. [↩]
- Here is my March 2012 review of Quiet. It’s a fascinating read regardless of where you land on the introvert/extrovert spectrum. [↩]
- 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. [↩]
- 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. [↩]
- 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. [↩]
- The definition comes from Ian Tucker’s interview of Susan Cain for The Guardian. (Source.) [↩]
- 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.) [↩]
- 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”? [↩]
- 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. [↩]
- Or at the very least: an environment that is disproportionately more taxing on you than it is on your peers. [↩]
- 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. [↩]
- Remember what Susan Cain said about the difference between being an introvert and being shy? [↩]
- Here is my July 2012 review of Team Geek. I’ve been recommending it to pretty much everyone that works in software engineering. [↩]
- 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. [↩]
- 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. [↩]
- 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 FrieselSoftware engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →
23 Responses to Agile for the Introvert
Interesting and well thought-out essay. I can’t help thinking, though, that you’re criticizing something you haven’t tried much.
I’m pretty introverted, and pairing does tire me out, but it’s not the exhausting interaction you get at (say) a cocktail party. It’s very structured and focused on the ideas at hand. Also, it’s one-on-one. Although I’m an introvert, collaborating one-on-one on code feels like an extension of my normal thoughtful work process, not an intrusion on it.
Now, I have known one person who was so introverted that she couldn’t pair at all. But she had other issues with that team, and I suspect her problems pairing had less to do with introversion and more to do with deep-seated team dynamics. Her team set up their workspace with a private office for her to work in, and they still had serious interpersonal issues. Eventually she moved to another job in the company.
This is all anecdotal, but in the absence of studies on Agile and introversion, I can only say “try it.” Pairing is uncomfortable at first, and it takes time to get used to, but as an introvert, I don’t find it to be a problem. The real issue is interminable whole-team meetings, but functional Agile teams should really be delegating decisions to pairs, not trying to decide everything in whole-team meetings.
By the way, I searched The Art of Agile Development for the word “introvert,” and you’re right–we never mention it. For what it’s worth, though, my assumption when we were writing the book was that most programmers are on the introversion side of the spectrum.
I focused on the pair programming because I perceived it as emblematic of Agile from a programmer’s perspective, and also because I felt it was the least criticized of the Agile elements. (Stand-ups and iteration demos being just another form of meeting when you get right down to it, and as such they need no help in the critique department.) To your point that I’m criticizing something that I haven’t much experience with–I’ll concede that my experiences with pair programming are not extensive. That being said, these experiences have not been uniformly bad, but they also have not uniformly improved my code quality either. I’ll be on the look-out for studies that examine Agile (and pair programming in particular) while specifically looking at introversion/extroversion. As you can probably tell, this is a subject I have much interest in; Susan Cain’s book cites some studies that suggest that techniques like pair programming may in fact result in reduced productivity, but I’d certainly be intrigued to see someone with evidence to the contrary. (I’m sure it works well for many folks, but I don’t believe it’s a one-size-fits-all solution.)
I’m not surprised that you did not find the word “introvert” in the text of your book (I was paying pretty close attention). I’m noticing that this is a kind of an “elephant in the room” for a lot of folks both writing and speaking about soft skills for software engineers. While I wouldn’t criticize anyone for assuming that most programmers are on the introverted end of the spectrum (after all, it fits a lot of the stereotypes that inform our views of the field), I also think that we over-estimate the number of introverts in the field (again: our own stereotypes and biases) and this further skews our perceptions.
Lastly: thanks so much for contributing to the discussion here!
Maybe this is all about going to extremes. You mention Thunderdoming. The teams I’ve been with (either as a team member or as a coach) were not in a Tunderdome or war room type of work environment. I’ve seen those environments but it’s been a while that I’ve seen the last one.
Software development and agile development in particular requires a lot of focus. It’s difficult to keep focus under constant interruption or in a noisy environment – actually regardless of what you do.
Being available and within earshot range to each other is a totally different thing. It comes down to basic manners. I don’t walk up to someone in a conversation and interrupt rudely. But it’s a totally different thing to have to call a meeting just to talk to someone or find that person’s office.
I completely agree that in the end it comes down to (As you put it) basic manners. The way I see it, “manners” vary based on organizational culture and are a reflection of what’s perceived as the “right” way to go about communicating or otherwise getting something done. I think we can all agree that an interrupt-driven company culture is going to force people out of their focus whether they’re operating as Agile or not.
I hope my essay did not come across as suggesting that sequestration was the ideal alternative. (Quite the opposite!) The question (to me) is how to balance the right level and right *way* to collaborate.
Excellent post; I’ve blogged about Cain’s writing and groupthink before.
I have plenty of writings on my blog that go into these aspects more (click on my name above).
I think there needs to be both collaborative and solo time;
Pair programming is not new — it was called working shoulder to shoulder in the past.
Just because people SOMETIMES work shoulder to shoulder, doesn’t mean they should always have to.
As always there is a balance and the Agile community ignores balance in search of extremes.
The comment above about “try it” and anecdotal is just the same old homilies.
The plural of anecdote is not proof, and people should not be required to try everything.
I think you are right that Scrum especially expects programmers to be like little performing monkeys who’s peanut is the demo at the end of the sprint.
Enough with the degrading nonsense
I know a lot of agile coaches and consultants; almost all of them are introverts. Not a paradox: effective work is more energizing than ineffective work, and many of us have found “agile”/XP to be very effective. We prefer to work that way.
Check out “Pair Programming Illuminated” for more info re introvert/extrovert pairing (and other combinations.)
Naomi Karten has written a lot about introvert / extrovert in the workspace… Not agile per se.
@Keith– I’ve been hearing that, that a lot of the Agile coaches/consultants out there are self-identified introverts. As I’ve mentioned in other forums, this surprises me. I get the part about effective work being energizing, and my question comes back around to: How do you adjust your strategy if the work isn’t energizing?
I’ll be sure to check out Pair Programming Illuminated, as well as Naomi Karten’s work.
Though I think some of tone of your response is a little on the non-constructive side, your point about “anecdotes vs. proof” is one that resonates with me. Most of the discussions I’ve had about this so far seem to come back to “well this works for me, and for XYZ people I know…” Anecdotes, not necessarily empirical studies.
To be completely fair: my own points are hypotheses based on anecdotal experiences. I’m eager to see some of the studies that others have mentioned.
Check out the voke report on agile for studies… it is enlightening.
Check out the rhetorical antipatterns page on my site for a catalog of issues like anecdotal evidence.
As per tone, that’s subjective I guess.
I am long past the point of cakewalking with the agilists….they give little respect to people with differing opinions, and after 12+ years of agile with no evidence of success, but plenty of evidence of commercializing placebo, I give them the same amount in return.
I recently read Susan Cain’s book Quiet. It kind of grew on my while reading that something was wrong with Agile, and then I started researching. Thanks for the good reading tips and for many good points.
Question for you: Given that introverts are likely to make up a brotherly portion of “developers”, do you think the Agile world will adapt to them in some way? In fact, I have a feeling this should be the next step in agile “evolution”.
After all, the agile manifesto values individuals and interactions over processes and tools. I would suggest that we find ways of interacting that enables both extrovert and introvert individuals to function well, instead of focusing on dogmatic processes and tools.
@Tom– Though I don’t have any evidence to back up the claim at this time, I believe that developers are split pretty evenly between introverts and extraverts, same as any other population. That being said, I wouldn’t say that Agile is adapting to introverts as much as each organization is adapting Agile to suit its particular needs, and its specific balance of personalities. As for whether “the Agile world” will make a shift toward this… I have some doubts about that, given that the claims seem to be “stick with it and you’ll see”.
I am an introvert. I was diagnosed with Social Phobia as a teen and have worked hard to overcome it. That allows me to speak in public and lead meetings as needed. It doesn’t remove the fact that I am an introvert. I can speak from personal experience on this topic.
Pair programming is VERY VERY VERY ineffective for me. In fact, I dreaded the idea of it. I also hated the idea of working shoulder to shoulder with someone. That also annoys introverts. In my last assignment, I never had any privacy. My computer screen was 12 inches from the guy sitting next to me. I also had a marketing guy in front of me who spent 7hrs a day on calls. I could never concentrate and get anything done until after hours. At home it was me, my computer screen, and my dog in the corner. I could concentrate there.
Just another perspective from a true introvert.
The mistake most people make is discounting the idea of someone being an introvert. You just can’t suck it up and be an extrovert so that you can be energized by ‘effective work.’ An introvert will never be converted to an extrovert. They will also never be totally comfortable in an environment catered to extroverts.
I don’t mind pair programming or sitting in a room together with other developers because they work quietly for most of the day. They are aware that constant jibber-jabber distracts their fellow devs.
The problem is when Agile is used as an excuse to make the devs sit right next to the analysts or project managers. Those people are constantly talking to each other or talking on the phone (which is totally legitimate — it’s their job to do those things), so it’s a constant stream of interruptions for the dev team.
Devs can bull-pen, but they need to be isolated from people with other roles who don’t understand how distracting they really are.
Agile/XP has effectively ended my 17 year as a professional software engineer. I can’t do it. I can’t get anything done, I live in terror all day in those environments. I suffer from extreme social anxiety and it’s really the reason I gravitated to computer science and programming as a career just because of that, and I’m damn good at it. Started in high school, hid away from everything in my room learning to write awesome software.
The article says “just say no to pair programming” and “withdraw and hunker down.” Just where are you supposed to “withdraw” to with everybody yelling and laughing and having pissing contests all day? Refuse pair programming? Not a team player!
All these terms, “user stories”, “scrum”, etc … what is this some kind of cult? like $cientology and all their little insider terms?
And there’s no autonomy for programmers anymore. Everything is run by the PMs now, they’re the chefs and the programmers are line cooks. Every freakin feature is separated into a thousand [confluence|rally|gira|…] tickets you have to manage, like you’re handling orders to cook hamburgers. The PM is in charge, the scrum master/manager is the gestapo enforcer.
Create a new branch or or sub branch for each and every one. Run the tests, merge to trunk. Do you have any idea how inefficient and disruptive all this is? How am I supposed to ever get “in the zone”?
Example: write restful API to control some widget. So you have your task. Fair enough. But then, task 1: implement the GET method. task 2: implement the POST method. etc etc etc. For each write write the tests, watch them fail, do the task until the tests don’t fail anymore.
You have got to be f’ing kidding me. Just let me do it in one shot, I’ll have it for you in a couple of days, don’t keep asking me how far I am, don’t be looking over my shoulder to measure my “velocity.”
In other words, f*ck you and your ridiculous cult setup. The worst part is this happened over night. I left my last non agile job to take some well-earned time off, a self-funded sabbatical to work on my own thing for a couple of years. Ok, now I come back and suddenly everybody is a 25 year old extrovert whipper-snapper or a kooky arrogant know-it-all bearded 50 year old wearing stupid self-congratulatory t-shirts, with math formulae on the back. And then they want to stay and play board games after work. If you don’t you miss out on the team-building and crap.
Haha, my last place the director was walking through “the dev pit” and was talking about putting tv screens up on the walls and joked “we can watch world cup games”. Being a naive idiot I thought “wow! that’d be awesome!” but nope, of course it was to have a constant display of the build status and crap. And there’s the “red light” when the farm is broken. lol. Sigh.
Good luck with that.
Sorry to hear all that, Phil. I hope you can find somewhere that supports developers and engineers better than that. What you’re describing sounds like a poisonous culture to me, and that place would probably be that way whether it was “Agile” or not.
Very few people are truly so introverted that they cannot collaborate 1-on-1. The points about interruptions and noisy environments are certainly valid.
Two things to consider:
1. The advice “Withdraw and hunker down only when you have a plan for your work.” is based on a misconception. There should be no such thing as “your work”. Whatever work you do belongs to the whole team as well as the customer. Much of the ugly legacy of the traditional approaches is work that some “genius” did that nobody else understands how to maintain, debug, extend, or reuse.
2. The traditional approach had specifications written by somebody who was supposed to understand all the requirements and moving pieces that were so tight that somebody else (called a programmer) could code up without understanding all the requirements and moving pieces. That kind of programmer could be effective hunkering down and just writing code.
Under agile, we believe that the person writing the code should also be the person who attains the best understanding of all the requirements and moving pieces and makes the best tradeoffs at coding time (instead of depending on the stale information that was known at specification time). This requires skills beyond heads-down coding.
I like to call that position developer to contrast it with the traditional programmer. A pathologically introverted person may just not be able to be an effective developer. It not only takes requirement elicitation skills, business analysis skills, and testing skills, but also the ability to interact with all the people necessary to be effective. Agile changes the job, even if people continue to call the position “programmer”.
Fast-forward two years and I owe an updated version of this post. The past year in particular has been quite eye-opening (esp. the months where I took a turn splitting time as a developer and ScrumMaster).
I agree that there’s no such thing as “you work”, and I agree that the notion of the “genius” is nothing more than a myth (see also my two-thumbs up for Team Geek), but I still maintain that pair programming doesn’t necessarily need to be the answer to spreading that knowledge around.
A more nuanced discussion needs to happen here. It isn’t that pair programming is never appropriate, but just as one could pathologically avoid it and cry “Introversion!”, the other extreme also holds — mandating continuous pairing because “Agile!” The ability to collaborate one-on-one, and as part of the larger team is absolutely important for a developer to be successful as part of a scrum team. But there are plenty of people that are going to need to (as I put it) “hunker down” lest they get over-whelmed and the whole environment becomes toxic for them. Again: it’s a balance thing.
As to your #2 point — drawing distinctions between “programmer” and “developer” seems like one that goes beyond any discussion of Agile or introversion. What you’re talking about is someone with good integrative skills (not just technical skills). I’d say this doesn’t have anything to do with Agile at all — that’s the difference between someone who “just code” and someone who can design and/or make broader judgments and/or build the relationships that go into building fully-fledged products and companies.
I am an Introvert and suffer from Social Anxiety and have found working in an Agile environment to make my life unbearable.
I came to have panic attacks before every daily stand-up meeting and found most of my day was spent in meetings which wore me out completely.
After 5 months, I just couldn’t do it anymore, I was a shell of my former self and ended up quitting. Now, as I find myself unemployed and looking for a new position I specifically avoid any job description that mentions ‘AGILE’ …
@ash– That’s terrible! I hope you’re able to get some help for the social anxiety. There are lots of good strategies out there for coping with that constellation of symptoms. (I’m sure it must have ripple affects into other aspects of your life.) Perhaps you could give an Agile organization another shot after getting that squared away?
I have anxiety disorder and am on managed medication for it. My organization recently switched to the bull pen and swallowed the Agile tenets whole. The first day in the bull pen I fell apart and suffered 56 (yes, I counted them) panic attacks in a row over the next month as I was put on a leave of absence. I had so many panic attacks resulting from that one day that my chest hurts and even my heart beating hurts me (my heart is fine but the muscular area is sore, multiple xrays and CT scans).
Three months later, I have returned back to work and on day two I’m already falling apart again. I keep hiding out in a small office I found but sooner or later, they will force me back into the environment and I will be in the hospital again. My anxiety manifests that terribly. I have applied for a technical position elsewhere in the company and as a result of Agile, my career in programming and applications development is basically going down the tube.
The depression resulting from everything I ever worked for falling apart is soul crushing. FYI, all my multiple therapists and psychologists and psychiatrists feel that this environment and ‘Agile’ business is not good for the human psyche.
Just my two cents.