38

This article "Agile vs Introverts" resonates with me a lot. To quote,

I had this thought: most of the “Agile” methodologies and tools are invented by extroverts ...

Introverts are not necessarily timid people, robbed of interpersonal abilities or avoiding others. Of course, for some people, this may be the case. However, it usually means that our energy reserves for interacting with others run out very quickly. We drain much faster than regular people. After such a period, we need to be alone ...

I am a big fan of the agile approach and close cooperation between the business and programmers. However, I also see problems with the agile approach.

As an introvert, I do not feel well when I have to spend a few days as an active participant in the workshops and I am forced to do pair or group programming.

From my experience, I see introverted team members feel more uncomfortable with agile. They are quieter in the daily scrum team, which does not mean they won't talk when they have problems but they are much quieter in the daily meeting. They prefer being left alone when programming. Last but not least, I see far more introverted engineers in our industry than extroverted engineers (although there is no hard evidence for this).

"Encourage them to talk" is much easier said than done. Besides, many software engineers I work with hold dear that "Talk is cheap. Show me the code."

How do I make agile process more comfortable for introverts?

PS, I guess there is probably no study to show there are more introverted engineers than extroverted engineers in software industry or introverted engineers feel more uncomfortable with agile process. But I hope we do not bury our heads in the sand and refuse to talk about/think about it (and just vote to close my question).

9
  • 2
    Are you trying to address a problem that you personally have experienced, or are you asking a theoretical question based on that one article? If the former, it would probably be more productive to ask individual questions about how to address specific issues. If the latter, I strongly believe you are asking the wrong people the wrong question.
    – keshlam
    Feb 11 at 14:36
  • 2
    Ok, so ask questions specifically about how to address the things you had trouble with. "How do we reinvent Agile" -- outside of the fact that there is more than one way to do Agile, and within them there are variations -- is probably too broad a question to get the kinds of answers Stack Exchange is designed for.
    – keshlam
    Feb 11 at 15:17
  • 1
    This may be a silly question, but have you tried asking them, and if so what were their responses? If you have their answers it would be easier to tailor an answer to fit your situation rather than writing a general purpose answer. Also have you considered that altering the process to accommodate them might create more problems for the extroverts? Feb 11 at 16:49
  • 1
    @StuartF. Scrum isn't even part of agile development (AD). It is often used in AD, and many think that they do AD just because they use Scrum. But Scrum and AD are orthogonal. Scrum can as well be used with waterfall development, and other methods can be used for AD.
    – md2perpe
    Feb 12 at 20:27
  • 2
    @Qiulang邱朗 the vast majority of instances users won't inform OP that they edited their posts. Nor is it their obligation (courtesy yes, perhaps). Anyways, you will know an edit was made as you will get a notification informing you that somebody edited your question or answer. Remember that (quoting from our Code of Conduct): "Be clear and constructive when giving feedback, and be open when receiving it. Edits, comments, and suggestions are healthy parts of our community." ... or in other words, Assume good intentions always :)
    – DarkCygnus
    Feb 25 at 2:23

10 Answers 10

58

Disclaimer: I know you said "agile", but I will talk about Scrum here, because Scrum has set rules that everyone can download and read and talk about. Generic "Agile" is different for everybody and so kind of hard to talk about here in specifics and not only vague notions and a lot of "it depends".

How do I make agile process more comfortable for introverts?

They already are.

Introverts have no mechanical problems with their mouth or tongue. They just do not enjoy talking to people or exposing themselves needlessly. If needed, they will talk.

As an introvert, I hate idle chit chat. The awkward silence or forced conversations in a meeting room before everybody is assembled or when someone (most likely the boss) is late. Meetings with no clear goal, where it's basically a paid sit-in for people to ramble.

Scrum does not do that. Yes, there are meetings, but they have a very clearly defined goal, a narrow scope, a time-box and even a "Referee" (aka Scrum Master) to make sure those rules are adhered to. To keep people from randomly chatting, going of course, rambling endlessly, jumping from topic to topic.

Scrum highly values "focus", something introverts should enjoy. Scrum does not include pair programming. It does not forbid it: you can add it if you find it useful; personally I don't. If I need another developer to look at my code and help me, I will ask. And in a good team, someone will step up and volunteer to help me, focused on a specific issue. Pair programming - forcing two to do it together, whether it's necessary or not - is not part of Scrum or generic Agile.

So how to make Scrum appeal to introverts? Show them how done right, it provides what they care for: very focused work, and very focused meetings, where you take the minimal amount of time necessary for the work you do, with no sidetracks, no small talk, no need to "socialize". It's a work meeting; it's treated like a work meeting.

Since a Scrum team should not be changing too frequently, your introverts will come to consider the team their "insider circle" where it's okay to be "exposed". They are their team. Not their potential enemy or competitor. None of them is competing with them for a promotion, because there is no hierarchy in a Scrum Team.

Now, this will happen if you implement Scrum correctly and if all members actually want to work as a team.

It can always happen that companies for various reasons don't manage to implement it correctly and/or have people on there who are not team players. Mostly extroverts, who hate the idea that they are not allowed to do their extrovert thing instead of actual work and that each meeting has a focus that is to be stuck to and a person that will tell them to stick to it.

The way to get introverts to like Scrum is to show them a good, well working Scrum team. Because you are right, talk is cheap. Action speaks louder than words, and saying "we use Scrum" is about as valuable and truthful as North Korea claiming they are a "democratic republic". Show them you do it right. And they will like it (or not, but that then has nothing to do with being introvert - there are lots of reasons for any given human to like or dislike something).

10
  • 4
    @mattfreake Do you have an example of those? I mean I do collaborate as needed, but if someone want's their peace to finish their programming part, I'm certainly not disturbing them... there will always be someone else on the team to help me. I don't think there are parts for Scrum where you are artificially forced to collaborate, if it's not needed.
    – nvoigt
    Feb 10 at 12:29
  • 3
    Some people are uncomfortable to give talks or talk in front of an audience, especially if it is about things like missed goals or road blocks they currently have in their work. There are more kinds introverts than just the people who do not like small talk.
    – allo
    Feb 10 at 14:17
  • 9
    In a scrum meeting you are usually talking for less than a minute, about stuff that is important for you so people can help you do your job. Most introverts I've known, even the most extreme, can handle that much. And as noted there are ways to do this without a meeting; scrum is far from the only way to do agile.
    – keshlam
    Feb 10 at 15:01
  • 6
    @keshlam Daily scrum isn't the only "scrum meeting". There is also sprint planning, review and retrospective. And proactively raising problems and asking for help can be difficult and many people struggle with that (it's quite dismissive to say "even the most extreme" introverts can handle that, and I guess it's not too surprising that you don't know the actual most extreme introverts or those with social anxiety, who may consider talking for a minute about anything in front of a group to be rather overwhelming ... because they tend not to talk to that many people).
    – NotThatGuy
    Feb 10 at 15:42
  • 6
    @Qiulang邱朗 I’m extremely introverted, I like to say "anti-social", and this is the answer I would have written. I very much enjoyed working with a team that used scrum correctly and effectively. In terms of agile in general: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". If you’re on an agile team with introverts, tuning to keep them comfortable and productive is required by the agile manifesto. Having an introverted scrum master helps. Feb 11 at 2:11
17

By asking them instead of us. I think the biggest problem with most "agile" processes are, that people use the methods without understanding their problem and the problem the method is trying to solve.
So firstly you have to find out what you're actually doing, what you need and what your team needs. Then you can find out how to do this with the least amount of time possible. Maybe that's scrum, maybe kanban, maybe shapeup or (and I always hope for this one) maybe it's your own method that fits perfectly for you and your team. Very important is that you also include other teams/departments in working out this method, if you have any dependencies and the power to do so.

And if all of that is a bit too much because let's be honest, we think we never have time for stuff like that, you can switch to more async communication. Why does everybody have to be in the standup meeting live and talk? Why not just send it via slack to each other in the morning/around noon or something like that? Why do you even need a standup meeting? Can you maybe do other meetings async as well? I actually switched our retro to be mostly async, we just discuss the next steps with the whole team, but everything else happens async.
Or maybe you can increase your cycle length and therefore have less meetings.

Don't let yourself be too focused on following a method and try out new stuff.

I suggest reading the ShapeUp Book. It's mostly about the shapeup method but the author also explains how they use async communication for almost everything and how it helps them to be much more productive and agile.

7
  • 4
    "By asking them instead of us. ", when I asked the question I was hoping that someone else can share their experience. Feb 11 at 15:01
  • 5
    @Qiulang邱朗 People are sharing their experience but you don't seem satisfied with the answers. You won't receive the answer you seem to be hoping for - people are different, you can't just divide everyone into two categories and invent a process that all people in one of the categories are happy with (be it by personality, gender, age, ...). Yes, on average there are likely differences in preference, but you are dealing with individuals, not averages. Why do you believe that asking the affected people is not a good idea?
    – Anonyma
    Feb 11 at 15:52
  • @Anonyma I have upvoted several answers. I have not accepted an answer, which doesn't mean I am not satisfied with the answers. Feb 12 at 3:08
  • "You won't receive the answer you seem to be hoping for" let me share another story to let you know how wrong this statement is. When I first asked my other question about scrum softwareengineering.stackexchange.com/questions/410482/… I had thought it probably would be closed as opinion based or people would make the similar comments like yours, but to my surprise, my other question got 226 upvotes. Feb 12 at 3:48
  • 1
    @Qiulang邱朗 That was just the impression I got from your repeated comments here. Glad to hear otherwise and thanks for clarifying.
    – Anonyma
    Feb 12 at 5:49
15

As an introverted software developer, I love agile. Why? Because it prioritises delivery over talking.

That means that people who are all talk and no action, the people who in other software development methodologies are able to thrive by doing nothing more than schedule interminable meetings where they talk about themselves, quite literally have no place in an agile environment. Because agile makes it very obvious that they aren't delivering any value.

(Note I am not talking about those who spend their days in meetings because that's their job description; good product owners, for example, are as essential as an IDE to keeping an agile development team delivering.)

And without the windbags and "managers" whose only management is of their own career and taking credit for others' hard work, I can deal with the extroverts no problem. Why? Because they're just as focused on delivery as I am!

Ultimately then, agile isn't about introverts versus extroverts; it's about the people who care about delivering good software, and those who don't. And because everyone in the first group is marching to the same tune, the introverts and extroverts in that group have no trouble working and communicating with each other.

4
  • 4
    Hmm, you brought up an interesting point, as in: maybe we don't speak up during a meeting, simply because there is nothing more to add to the current discussion (at least that's one of the points I understood when reading your answer).
    – Clockwork
    Feb 10 at 23:40
  • 2
    @Clockwork 100%. Introverts generally don't speak when they don't believe they have anything to add to a conversation; that's completely unrelated to any (perceived) awkwardness.
    – Ian Kemp
    Feb 12 at 10:46
  • 5
    @Clockwork As an introvert, this is a big thing. I often see people (mostly extroverts) worrying that we're missing out on something if we don't make sure everybody contributes something, and trying to fix it by imposing a rule that everybody has to talk. The net result is that I'm only half listening to half of the meeting, as I'm anxiously trying to come up with something "good enough" to say for my turn. Even the daily stand-up often does this if it's presented as "everybody say what you're up to" instead of "anybody can let the team know things they think the team needs to know".
    – Ben
    Feb 13 at 5:01
  • @Ben I can tell you that it is very relatable, yeah x)
    – Clockwork
    Feb 13 at 6:06
12

How do I make agile process more comfortable for introverts?

Keep the team small.

The classic rule of thumb is that if it takes more than 2 pizzas to feed your team it's too big. If that's too fuzzy for you, Research by Richard Hackman and Neil Vidmar says the optimal size is 4.6. However, the 2 pizza rule completely fails to explain why a small team is critical. Some like to go on about communication following quadratic growth formulas like n(n-1)/2 but the real reason is more fundamental than that:

Talking to your team shouldn't feel like public speaking.

10
  • 1
    @PeterMortensen Research by Richard Hackman and Neil Vidmar says the optimal size is 4.6 Feb 11 at 15:09
  • 2
    If you know a study saying 4.6, then please don't say "between 1 and 12" in your answer. It will take two average pizzas to feed me alone, but if you order big pizzas then two of them might feed 12 if they eat as little as some people I know.
    – Nobody
    Feb 11 at 15:38
  • 2
    @Nobody - I dont see "between 1 and 12" anywhere in that answer or comment.
    – StingyJack
    Feb 11 at 15:43
  • 3
    @Edward what I said is that the pizza rule is the classic rule of thumb. And it is. Some people value hard won experience over theory. But if all we care about is being pedantic I can play too. No one should ever consider the pizza rule because some people are lactose intolerant. :P Feb 11 at 23:49
  • 3
    @Edward - I believe that you and Nobody are getting hung up on the intentionally loose example that was used to give the actual answer the right amount of impact. Try skipping over the entire answer except for the last sentence and see if that helps you. Also we can cite studies all we want but averages from a study literally wont even work here unless someone can produce 0.6 of a person. Even then you have to know that averages and optimals are not always the right values for every situation and circumstance.
    – StingyJack
    Feb 12 at 3:20
9

Have you actually asked your introverted team members if they are feeling uncomfortable?

Being introverted also doesn't automatically mean that someone doesn't like closely working together with others. Some parts can be more exhausting, true, but even introverts tend to be social creatures (as a lot of us noticed when doing only remote work during Covid19 lockdowns). It can be really motivating to be part of a team with a common purpose.

Nothing in what you are writing indicates that your introverted team members are not doing their work well. Why do you feel you need to encourage them to talk more? You say that they are quieter than extroverts in your daily standups - I'm honestly not sure why that comes as a surprise. But you are also saying that they speak up when there are problems, so what is the actual problem that you are trying to solve?

Please do not make the mistake of deciding yourself what you think is best for everyone just because some people are not that outspoken. If you believe that it could be (or indicate) a problem, why not organise a retrospective about the topic or ask your Scrum Master to do so? Make sure everyone gets the chance to speak up. Listen to them.

And if it turns out that some part of your process doesn't work for the team? Well, in the end it's "people over process". If something doesn't work, the team should be free to try out something else.


For context: I have been working as part of agile teams for 5 years now - as a very introverted person myself, and probably the most socially awkward one on my current team. Despite that I've also been our Scrum Master for the last year and have received positive feedback in the role. Except for the first week or two in a new team (when I didn't yet know the people and the work) I've never felt that my personality was a particular hindrance regarding communication inside the team.

2
  • 3
    This. Don't try to second guess everything. If you can, ask the concerned persons/parties directly. It's always good to hear from them.
    – Clockwork
    Feb 10 at 23:37
  • 1
    Indeed. It could be that they enjoy the stand-up meetings, but not the inapproachability of colleagues outside of the stand-up meetings (for example, always "too busy"). Just as an example. Feb 11 at 6:17
5

From the POV of your question, there are two types of jobs:

  1. jobs which require people to interact: clerks, politicians, actors...
  2. jobs which individuals can do without much interaction.

Now, it should be obvious that two people cannot edit the same piece of code simultaneously in a successful manner. So, programming is a job which is mostly done alone.

What Agile people dread is not working alone, it is writing documentation (see the "Working software over comprehensive documentation" in the Agile Manifesto). So they prefer to sacrifice their introvert-ism for the sake of avoiding writing documents.

And now you come from the opposite direction, dreading the meetings looking for another "agile" solution.

I could continue on a sarcastic tone, but I will point out what is obvious to me: you need to find the good balance between documentation and meetings. Considering that Agile is not totally against documentation, you need to find out which info is usually required in the meetings, and make that information available in a written form.


I do not have a scientific reference for this, but there is some piece of "wisdom" running in the companies: the meetings are the metric for the quality of work - more meetings are the result of bad work, and bad work generates more meetings. To the point that all the work is replaced with meetings discussing about the bad work.

With this in mind, the alternative (not exclusive) path is to find out what actually goes wrong, and fix it.


Note: none of the proposed solutions above can be done easily by a single person, especially if the person does not have a position of power in the company.


Another note: Since I never worked in an agile environment, I might be wrong in this statement. The referenced article starts with:

I had this thought: most of the “Agile” methodologies and tools are invented by extroverts.

and I kind of disagree. It kind of sets the wrong premise for the discussion. Agile is not about introverts vs. extroverts, it is mostly about spaghetti code writers against processes, against tools, against contracts, against documentation and against following plans (please see the liked Agile manifesto again).

And in spite of the wrong premise, there are some good point highlighted in the article. Until the guy attempts to improve Agile by doing anti-agile:

  • preparing for a meeting by writing down what is to be done
  • writing the proposal in the form of Architecture Decision Record or Change Request

Just saying, mixed feelings...

20
  • 1
    OMG, in your other question (softwareengineering.stackexchange.com/questions/410482/…) you already received several answers (from real experience, not theoretical like mine) that the problem is with Agile / Scrum, not with introverts and extroverts, and neither with good developers and bad developers. But you keep massaging the wooden leg...
    – virolino
    Feb 10 at 10:02
  • 2
    @nvoigt: "a meeting that is supposed to reduce written documentation" - it never crossed my mind. But a lot of meetings have the purpose to clarify things. These meetings can be replaced by change requests (bug reports etc) and specification documents. These 2 (types) of documents are assigned to the right people and monitored to completion. Meetings should happen just to report progress, if everyone is doing their job properly. The bug report highlights the problem (and tracks the implementation until completion), the specification is the repository of information.
    – virolino
    Feb 10 at 12:31
  • 1
    I'm also unclear on the "meetings to clarify" thing... I assume you mean the "Refinement", formerly known as "Grooming". But that alreadey assumes you have a written Ticket that you can discuss. I don't think tickets magically get more clear when you label them "Change Request" instead of "User Story". What happens when the "Change Request" is unclear in traditional non agile worlds? Wouldn't you meet and clear it up? I'm old enough that I worked before "Agile" was a thing and that is exactly what we did...
    – nvoigt
    Feb 10 at 12:40
  • 1
    Well, that never happens (or at least not by design) on a Scrum team. I would admit I have never worked with people skilled enough at documenting, that working off of documentation would actually produce satisfactory results without those "omg, what a mess, full stop" meetings you mention, I guess you never worked on a working Scrum team (both I will admit seem to be oddities among the millions of companies afloat). Maybe I underestimate the power of good documentation, maybe you overestimate the amount of meetings saved by it and the truth is somewhere in the middle :)
    – nvoigt
    Feb 10 at 13:12
  • 2
    @DavidR Sure, sounds like hell. But it isn't in any way "agile", so I'm not sure what the point is. The Agile manifesto says "Working software over comprehensive documentation", so the agile solution would have been to have neither the meeting nor the documentation and instead have the guy come over and give you access to and an explanation for their working sandbox, so you can at any time just test it and ask them instead of leafing through a dusty binder or their wiki equivalent.
    – nvoigt
    Feb 10 at 15:47
2

There's a lot to unpack in this question.

Exactly what problem are you having with the "introverts"? That they are not talking enough in meetings?

The explanation for that, in my view, could be as much to do with the size of the team.

There's a big difference between a cosy meeting consisting of two people you know well and share your understanding of the topic at hand and knowledge of recent events, and a meeting consisting of quite a few strangers.

In other words, there may be nothing wrong with the method, the meetings are just so large as to be intimidating to the average staff member who might say more in a smaller circle of colleagues.

Another problem could be the perceived complications of the subject. If the quieter people tend to have better or deeper understandings, then communicating about it might be more difficult than for those who have very simple and shallow (perhaps even unsound) understandings.

Moreover, attempting to communicate about something complicated often requires preparation and notes, and competes for time and mental energy with actually performing the development work. If meetings are as frequent as daily, there may simply be no time to talk effectively about the work - and rather than gallop through a garbled summary of the work, the "introverted" types may be more inclined to just say nothing.

Another possibility is that some people are remaining quiet because they don't understand how the time is being used effectively - whose or what purposes the communication is supposed to serve.

There are many explanations that go beyond some people's mere shyness or introverted orientation.

3
  • 1
    There is not a requirement that introverts -- or anyone -- talk in meetings when they don't feel they have something to contribute. Even then one can usually raise the issue with whoever is leading the meeting offline and have it dealt with in the next meeting. And Agile, by itself, does not absolutely require meetings. A separate question about how to run meetings for mixed audiences might be appropriate, but I think we already have some.
    – keshlam
    Feb 11 at 16:58
  • @keshlam, indeed but I assume the question was asked because the OP feels the "introverts" are talking "too little" by some standard. Be a hoot if he just didn't realise there wasn't anything to say!
    – Steve
    Feb 11 at 18:35
  • 2
    The stated goal was making the process more comfortable for introverts. One way to do so is to drop assumptions that one must speak more.
    – keshlam
    Feb 11 at 23:57
1

You can ask them more helpful and friendly questions during the daily scrum meetings to encourage them to provide useful info.

The questions you ask should be directly related to the tasks that they work on.

For example, some questions could be:

  • Do you have any road blocks so far ?

  • Is everything still right on schedule as expected ?

  • Are you waiting for someone to provide input or to integrate with your module?

  • Do you think you are still making good progress so far ?

  • Do you think you may need more time than the allocated time to complete the tasks?

  • Do any other developers wait for your tasks to integrate ?

The main point of these questions is to encourage them to provide more info to you, and other developers who attend the meeting, and also to make some correction to the development plan if necessary.

Therefore, the tone of the questions should be calm, friendly, and professional.

That will make them feel like this is a helpful conversation that they want to engage. They may enjoy the daily meetings more and more this way. Eventually, they will get used to providing more useful info during the meeting.

Don't make them feel intimidated or pressured by your questions as if the big boss is watching them.

1

Make participation in agile/scrum optional for them. Tell them to post their updates in Slack instead of face-to-face standups. Pretty much anything that can be said in a scrum meeting can be said in Slack.

0

I like to put a heavy focus on psychological safety within the team as, in my experience, introverts feel much more comfortable with all the agile ~stuff~ when they feel safe in the team and they are comfortable with their colleagues.

A good resource to look at with this is Mehmet Baha (I am not affiliated; I just saw him speak recently).

You can also work on team building, getting the team to know each other (and by team that includes PO and SM if you have them). I like to start every retrospective with a warm up (Again, I am not affiliated; it is just a good tool.)

My experience, for your reference, is that I'm a Scrum master. I have been for about three years now and have helped five teams so far (not all at once of course!), but I have also done a fair bit of relevant training.

9
  • 12
    Those warmup games sound like an introverts worst nightmare! Feb 10 at 12:27
  • 3
    @DavidLindon Agreed. Just thinking about something like that makes me throw up in my mouth a little. People need to understand that introverts are not necessarily shy, timid, conflict averse or otherwise unable to stand their ground. Most of us aren't - we just want to get ON with it. We just dislike the idle chitchat, the never ending socialization. it consumes energy and has no useful output. I detest insecure extroverts, you vampires, stop stealing my energy just so you can feel better! arrgh. </rant>
    – Stian
    Feb 10 at 19:55
  • 3
    Stupid games are the number one way to make me hate you as a scrum master.
    – Ian Kemp
    Feb 10 at 21:28
  • 1
    If you are spending time in a scrum meeting doing anything but "These are the things I've finished since the last scrum meeting, these are the things I plan to work on until the next scrum meeting, this is what I need from others so if you can help please talk to me after the meeting", it's drifting away from being a scrum meeting. Hold team building exercises at another meeting.
    – keshlam
    Feb 11 at 17:34
  • 2
    To elaborate on my previous comment, because it's not particularly helpful for scrum masters wanting to improve: these "warm-up games" are the kind of games a teacher would play with young children, and software developers are not children; we are knowledge workers, and strangely enough we find it incredibly demeaning to be treated as anything but. Further, the fact that you as the scrum master are controlling these games places you in a position of power similar to a teacher, which is again demeaning as well as fundamentally incompatible with the equality that agile preaches.
    – Ian Kemp
    Feb 12 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .