Scrum for Introverts: Expect Team Collaboration

In my level set post, I talked about some common patterns organizations follow when implementing Scrum that can be especially onerous to those who need their alone time. I’d like to focus today on the means many teams use to collaborate, how those means could create problems for more introverted folks, and contribute some ideas for how organizations and teams can produce a more hospitable environment.

The Expectation

We must start by expecting the need to be flexible and adapt to the specific and necessary things individuals needs to feel like themselves and do their best, most creative work. This is assuming we’re talking about non-routine problem-solving work like software development.

You should expect your team mates to crave raucous conversation and group interaction. You should even expect them to crave so much of those things that you begin to feel drained and burned out.

You should expect your team mates to crave intimate conversation and quiet reflection. You should even expect them to crave so much of these things that you begin to feel that jittery need to get up and walk around to see who want to play ping pong.

You should expect your reports to rebel when you call that new status meeting. You should expect them to ask, even demand that you provide them a subjective analysis of your reasoning.

The Space

No spaces are created equal. The needs of the team must dictate it’s configuration, utility and noise level. If a team is largely extroverted, piling them in the center of the room facing each other may be the absolute best option (especially if the team chooses it). If the team wants very much to have enough nooks, office walls, doors, and hidey holes to house every developer you should strongly consider meeting their desires.

If the team wants screens displaying build status, kitchens for conversations, couches for lounging, and standing desks for kinesthetic standing work, consider meeting their felt needs. If they want a spartan environment, free of visual noise or distracting activity consider meeting those needs as well.

If the team wants the freedom to have frequent (sometimes loud) conversation, a soundtrack for the day, and the occasional group activity, consider accommodating these needs. If the team craves a serene zen garden, the babbling of a waterfall, or separate spaces for group activities, considering making that excellent stuff happen

As with everything, wisdom must dictate not only the choices of the team but the response of the organization. If the team desires a busy, open, and raucous space determine if it’s their extroverted need or a lack of focus on their day to day work driving their need. If a team desires separate offices for members, no information radiators, or absolute silence, consider if individuals are resisting working as a team. Regardless of the tendency towards introversion or extroversion, the group must be willing to work as a team. If this is attitude is prevalent, this team’s request are very likely the key to understanding their spacial needs.

The Team

Understanding how groups of people are transformed into a team is the first step to uncovering the means of establishing a hospitable environment for both those more extroverted and more introverted. A group becomes a team when they are catalyzed to accomplish this goal. Professionals recognize the needs of their teammates and will order themselves accordingly. This is not to say that people make perfect, rational decisions — far from it; yet, given the freedom to self-organize, people will generally do right not only by the organization but also by their teammates.

A group of people working towards a common goal who consider each others personal and professional needs and who possess all the skills necessary to achieve their goal have finally become the Development team described in the Scrum guide. These people have the wherewithal to accommodate each others needs and the organizational support to make those accommodations reality.

The Work

The way the work is done should be up to the Development team. Period. If they alone are responsible for the quality and the soundness of the Increment of software, who are we to impose a different way of working? Doing so amounts to a form of subtle control known as toxic delegation that we should avoid strenuously. Do not mandate that every feature or bug be pair programmed. Before you quote me the proof of it’s effectiveness, know that I have done the same on many occasion. It is a circumstantial metric. If the team is able to produce high quality, high value software without a bit of pair programming, who am I and who are you to insist that developers change way they work?

Viewing the empirical results of a way of working will carry the day. A team may decide they want to work a certain way and may be shown that their way of working is producing poor results. This eliminates the heavy-handed tactic of mandating a particular way of working. Ultimately,

a poorer way of working that the team chooses is better than a theoretically better way of working that the team is forced to follow.

Do not lose site of the principle of agility that states,

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. – Agile Manifesto

Ultimately, the team is accountable for it’s results. These results should be clearly defined so the team knows well if it is producing those goals. To do less and mandate a way of working is a sort of laziness that is tantamount to the sort of tyranny imposed by a mall cop.

The Wrap-up

If we claim to value “Individuals and interactions over processes and tools…” we must expect people to be different and have different needs in the way they interact with one another. We must then require them to work as a team with the realization that teamwork is only possible with a collective goal. Once this requirement is made, an organization needs to define the results expected and collaborate with the team to see that those results are produce. By doing so, we de-couple the concern of introversion and extroversion and instead establish an interface with the team behind which they may feel the autonomy to act and interact as they choose.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.