Agile For Introverts: Re-Imagined Programmer Collaboration
Agile For Introverts: Re-Imagined Programmer Collaboration
The core idea of Agile for introverts: draw out the best contributions from a team by tweaking the ceremony of contributing.
Join the DZone community and get the full member experience.Join For Free
I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.
In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.
This made me wonder what some Scrum ceremonies or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “Let’s all get together and collaborate always!” was the right way to think.
What is Introvert-friendly?
Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.
I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.
I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus. I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited. You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.
- Appeasers, Crusaders, and Why Meetings Usually Suck
- Why Social Situations Exhaust Introverts: A Programmer’s Take
- Meetings and Introverts: Strangers in Strange Lands
There are probably more, but these certainly capture some of the themes at play here. And from this basis, I propose the following concepts as introvert-friendly:
- Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
- Meetings and gatherings are limited in size.
- In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
- Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
- The most productive work happens in a state of flow when you can tune the world out and concentrate.
- It’s worth letting a group make a sub-optimal choice to preserve social harmony.
- It’s good to be able to opt out of groups that frequently make sub-optimal choices.
Notice that none of this is, “I want to be home, alone, always, with no interaction.” That’s not introversion — that’s being a recluse. Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”
It’s not entirely fair, but I tend to think of Scrum as the process half of Agile and of XP as the practice half. Because of this, I tend to think that the scrum ceremonies and processes are the most ripe for re-imagining with different social dynamics in mind. After all, XP has a lot of things about continuous integration, TDD, story slicing, refactoring, etc. All of these are things that don’t require any specific process nor any specific collaboration paradigm. There are, however, two notable and prominent exceptions: pair programming and the open work space. And before I (in subsequent posts) opine about changing Scrum ceremonies, I think it’s worth addressing these first.
To hear Susan Cain tell it, these edicts of XP are anathema to an introvert programmer, both in terms of morale and productivity. But, I’m not Susan Cain and I won’t make that claim. What I’ll do instead is tell my own, introvert story of navigating through my career, with large swaths spent in these sorts of situations.
I’ve acquired a habit of working 10 or more hours a day. I’m not sure exactly when this started. In college, I was more prone to slack and binge cycles of work, procrastinating dangerously and following up with Herculean efforts to get things in and decent ahead of the deadline. As an adult, I got a bit more serious and started evening out my work, but that took me from the standard 8 hour work day in the beginning to a steadily longer routine over the years.
I’m ambitious and conscientious, particularly now that I’m no longer prone to procrastination, but there was more to it than that. I gradually became addicted to the after-5 quiet of the office. I would arrive at 9, collaborate with people all day, attend meetings, be interrupted, and generally be a good corporate citizen, and 5 PM would arrive with me having accomplished almost none of what I set out to do for the day. Then everyone would shuffle out of the office for the day, with the exception of myself and a few others like me. We would work in conspiratorial silence from 5 to 7 or 8 PM. And it was in those that the day’s work would get done.
I’ve spent a lot of years pairing on code and I’ve spent a lot of years in open, collaborative spaces. Every time I moved to a more open space, I thought I would hate it, but I’d wind up liking it. And pairing? That was just like college when I’d bond with a buddy over a 36 hour marathon to get our CS-451 homework in on time. The idea that these things are ipso facto introvert kryptonite is drastically overstated, and thus the “suck it up and come out of your shell” sentiment is something of a canard. If you consider my definition of “introvert-friendly,” you’ll see that open workspaces are only stressful when there’s an over-abundance of stimulus, and I’ve worked in open spaces that did not have this. And pairing is actually a great social activity for introverts — it’s controlled, with a clear social pattern, and a necessarily limited number of participants. I’ll pair all day if it keeps me out of meetings.
Pleasant, But Marginally Effective
These activities have thus actually been pleasant for me over the years and not odious. But they’re also not how I work effectively. If they were, I wouldn’t spend all day enjoying the camaraderie with my coworkers and then get the real work done after they all leave. In a lot of ways, these extrovert-ideal activities are like alcohol (which is, itself, essentially “extroversion juice”) for me — good for socializing, fun, but a handicap on my effectiveness.
I’ve seen some compelling studies that suggest nothing is more effective for reducing defect counts than peer review (I believe this was in the iconic Code Complete, by Steve McConnell), so pair programming, which is constant, live, peer review clearly would help with that. I don’t dispute that at all, but I do submit that I don’t equate avoiding mistakes with being effective. Avoiding mistakes is good for certain kinds of work, while making them, internalizing them, and learning from them is good for other kinds. And it is this latter kind of work, almost without exception, that has amounted to the most successful and career-defining achievements that I’ve had. On the whole, my hypothesis is that collaborative work like this is extremely effective at creating a sustained state of “marginal-flow” where you don’t get sidetracked by Facebook, but where you don’t have enough leeway to pursue the kind of blind alleys and yak-shaving that lead to meaningful, difference-making advancements.
For years, I’ve collaborated like a good soldier. Even to this day, I participate and do so cheerfully. But I think it makes a powerful statement that I’ve essentially become a workaholic because it’s the only path to enough working hours at peak efficiency for me to feel satisfied. And, frankly, those last 3 hours of the day were pretty relaxing after with a full day of exhausting meetings and collaboration.
There are times where the absolute most effective thing that a team can do is sequester itself in a war room and collaborate for 10 hour days. Maybe it needs to rescue a piece of legacy code, squash the bugs, and ship the thing in an incredibly tight window. There isn’t time for intent to be lost in email chains nor for issues to fester. Everyone needs to be able to yell out which file he’s touching and have snap, instant communication. This is what the open work space was meant to address, and it has value.
But there are times when you want to task your team’s cerebral math guru to come up with a creative, unprecedented way to route network traffic, and she’s going to need peace and quiet. That’s not the kind of activity that’s going to be aided by someone keeping her off of Facebook and a team of people yelling, talking on the phone, and making noise. It’ll come from her staring into space, scribbling unintelligibly on scratch paper, and, believe it or not, brainlessly browsing Facebook from time to time.
Why not recognize the validity of both working modes and that people will find different each mode appropriate at different times? How about a square-ish space with a ring of offices for the team and an open, collaborative space in the middle? And why not let the decision about how many people jump on a task be an ad-hoc, voluntary one? An introvert, tired of a week straight of working with 2 or 3 people could volunteer for a solo card to recharge a bit and feel more productive. Extroverts, who work more effectively in these conditions, could be full throttled paired-plus all the time.
Worried that the introverts would retreat into their office never to emerge? Instead of setting policies that force them out, why not lure them out? If you want them out there, limit collaborations that involve a single person dominating the group discussion or that involve a lot of yelling, boisterous talking, putting people on the spot, and interrupting. For introverts, open office work plans are often uncomfortable enough that you have to mandate participation in much the same way that you’d have to drag a dog into a room with an air raid siren blaring. And even when you’ve dragged them out there and pressured them into exhausting themselves playing pretend-extrovert, you’re still not getting their best.
If you want to maximize the effectiveness of your team members, I’d offer them as many options as possible and see where they go. One of the things I most often hear in the context of helping organizations move from relative formalism to agile methodologies is, “let’s not introduce any more process than we have to.” Why not apply this to collaboration paradigms? Let your introverts and extroverts work in the ways that best suit them until something isn’t working, and only then, consider a team norm.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.