How do I make agile process more comfortable for introverts?

Question

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).

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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...

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.