The Agile Manifesto and the ensuing emergence of Agile development methodologies were a great step forward in helping the software industry move past the clunkiness and slowness of the existing waterfall-like methods. However, Agile is a methodology authored entirely by western males in an industry dominated by men. Because of this, Agile relies on values, thinking processes, communication practices and working styles that are comfortable for western males but not necessarily aligned with other types of people. For instance, Agile assumes that all team members have equal privileges with respect to communication and bringing their ideas to the table. Agile inherently values speed (velocity) and pace as an appropriate measure of productivity. Agile assumes that the best solutions emerge naturally from self-organizing teams working incrementally in close collaboration with the customers. 

While Agile has many good features as a methodology for software development, the Agile assumptions work against members of the non-dominant groups in a workplace. This is because:

• Agile approaches do not take into account that employees of the non-majority group are often muted, and therefore do not incorporate into its routines mechanisms that enable their voices to be heard and factored into product and team planning.
• Agile approaches do not take into account that different people process, reflect and work best at different paces at different times. It tends to penalize people that process more slowly and/or more deeply, for example.
• Agile approaches do not tend to take into account that listening to and planning around minority group values and priorities takes time and effort, but may unearth more problems earlier, may spur products to be more creative, and may better support a wider variety of customers. 

In order to bring together teams that include and embrace input from these groups, and to reap the benefits of being truly diverse and equitable, Agile needs to be agile. We need to take steps to examine its assumptions and understand where to make changes. Doing so requires bringing members of other groups into the software methodology discussions, listening carefully to what they have to say while factoring out  our own natural biases, and enabling them to provide honest feedback and input on how these methodologies can evolve to support a more diverse and inclusive work environment.

Basic concepts in group psychology

Before launching into a discussion of Agile, there are some key psychological concepts that are useful to understand.

We start out with a notion of groups. Whenever you have a number of people working together, they will form into groups naturally. These groups may form based on things like common traits, experiences, cultures, and interests. We mentally have an affinity towards people in our own groups, and attribute different levels of respect to others based on the groups where we mentally place them. We are more inclined to listen to and accept some groups over others. Our in group consists of people we perceive as sharing many of our beliefs, attitudes, values, and language of communication. With the other groups, our out-groups, there is less overlap.

This natural clustering of coworkers into groups has several effects. The dominant group at work, the organizational in-group, defines the tone of the working conversations. It dominates the values, thinking processes, communication processes and working practices of the group. The coworkers who are in a minority group must make a greater effort to understand the dominant group’s values and thinking. They must take the effort to make their communication, and working practices “fit in”. This innately places a higher cognitive load on the people in the out-groups, which leaves them with fewer reserves for their actual work. This is explained in more detail in my article on masking.

In addition to the increased cognitive load there is the problem of in-group favoritism and out-group negativity. In-group favoritism is “favoring members of one’s in-group over out-group members … in evaluation of others, in allocation of resources, and in many other ways”. Out-group negativity is “punishing or placing burdens upon the out-group”. How out-group negativity often works out in the workplace is that behaviors that are acceptable from a member of the dominant are punished when done by a member of the minority. For example, in a setting dominated by males, if a male is assertive that may be considered as a leadership strength, but if a female does the same thing she is more likely to be considered to be pushy and her behavior something to correct (e.g., see Gender Bias is Real).

Finally there is the issue that minority groups are often muted. The muted group theory states that the dominant group is the group that creates the communication system, and that members of the minority need to learn the dominant group’s communication system in order to express themselves. Because the minority groups have different values, thought processes, etc., they may be unable to express their ideas clearly in the dominant group’s communication system. Because they have difficulty expressing themselves, the minority groups often are ignored by the dominant group. This leads to the members of the minority groups being “overlooked, muffled, and invisible” [1].

To summarize, because we as humans naturally form groups, with one group dominating, members of the minority groups inherently have problems with communication and fitting their working practices into those of the dominant group, with being productive in the face of additional expectations that are placed on them, and with speaking and speaking up in settings where their ideas are overlooked and suppressed. These consequences follow from basic psychological principles.

How Agile Assumptions Impact Inclusion

As I mentioned before, the Agile Manifesto was authored by a group of western men, and thus inherently leans towards that kind of value system. The Agile Manifesto works hard to address the real problems inherent in waterfall software development methodologies. It is important to preserve the real forward progress in development speed and flexibility that we gain from Agile methodologies as we evolve our best practices for software development. However, due to the nature of the committee that authored it, their underlying biases are incorporated into the proposed solution. These biases include values concerning communication and collaboration, measures of productivity and methods for making progress. These are not necessarily bad values. Rather, they are values that are biased towards a particular way of thinking and working. Hence, they do not always mesh with the values of a more diverse population.

In this section, we will discuss six basic assumptions made within the Agile manifesto and how they work against making our Agile teams more inclusive.

Assumption 1: Communication is a universal privilege

The values in the agile manifesto include “Individuals and interactions over processes and tools”, “Customer collaboration over contract negotiation” and “Responding to change over following a plan”. In other words, you figure out things like project objectives and requirements by interacting (usually verbally) with the customer, preferably on a regular basis. The development of the product becomes a (mostly oral) team effort between the customers/stakeholders and the developers. 

These values make the inherent assumption that the privilege of being able to speak and to be listened to is shared equally by all. However, when you enter a diverse corporate setting, where there is a dominant group and one or more minority groups, this assumption cannot be made. Likely, the privilege of being able to speak and to be heard and respected is owned almost entirely by the dominant group in the workplace. Muted group theory states that these design conversations are likely to take place using the language and communication processes of the dominant group. The resulting design reflects the understanding and concerns of the dominant group. The tendency will be to mute the members of the minority groups; their voice will become overlooked, muffled and ignored. The values, priorities, suggestions and ideas of the muted individuals do not get brought to the table, or get dismissed quickly. This effectively removes them from the collaboration. 

Assumption 2: We all communicate best the same way

One underlying tenet put forth in Agile is that oral communication is the most efficient communication method:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

– Agile Manifesto

Face-to-face communication can be efficient in the situation where all people feel equally comfortable and able to engage in it. This is often true among the members of the dominant group. However, muting, by definition, means that the members of the muted group are less comfortable engaging in the conversation and/or speaking up, even when they have the capability to articulate their input clearly and their input is important and/or significant. Additionally, some minority groups do not do well with speaking as a form of communication, but still do valuable work. For example, a person who speaks English as a second language may need extra time to process verbal input and to  understand English-based nuances in what people are saying. Some autistic people think best in writing or pictures, and at the same time often have different and useful perspectives on the challenges at hand. People who are wheelchair-bound often have their heads at a different level from others, which can be a barrier to breaking into a conversation. Deaf people may need to communicate through assistive technology. The ultimate result of relying heavily on face-to-face communication in Agile organizations is a tendency to discount and undervalue minority groups.

Contrast this approach to systems that use processes and tools, and contract negotiation. These systems usually include some form of writing down things like architectures and requirements. A communication approach that includes more writing and relies less on face-to-face conversation often helps in situations where oral communication is difficult. A combined oral/written approach enables members of more different groups to understand common design and implementation goals, which helps them work together more efficiently. Writing things down increases the number of different channels of communication and helps those who learn and communicate better through writing or visualization. 

Writing things down also gives everyone mental space. All of us do better when we have space to think and process. Face-to-face conversation requires a person to process in real-time, and is often strewn with challenging behaviors like people  interrupting or speaking over other people. Writing things down provides room for people to understand and reflect more deeply on the things that are being discussed. While it is important not to go too deeply down the reflection rabbit hole, some deeper thinking can streamline software development and help avoid problems in the future.

Assumption 3: Velocity is a good metric for overall productivity

The Agile approach of frequently delivering small increments has many advantages. The stakeholders have an early idea of what the product will look like, and can react appropriately. Early hands-on experience with a product provides the  opportunity for the perhaps not very clear requirements to be embodied into something concrete and accessible. It helps the end users to bridge the gap between description and hands-on visualization. Seeing a concrete prototype or visualization can help people resolve ambiguities and can be used to sharpen and modify requirements. This value is embodied in the Agile methodology:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

– Agile Manifesto

This idea of delivering in small increments has led to the use of velocity as a metric for the success of an agile team. If you assign points to increments, you can then measure productivity by measuring how many points a team completes in some period of time. This view of productivity, however, prioritizes quantity over quality. If your metric for productivity is velocity you will work to improve it, simply because you are measuring it. However, velocity just means you deliver stuff quickly. It does not mean you deliver features well. It does not mean that what you deliver will meet the wants and needs of your diverse set of customers who will use the products and services you are developing. It does not even mean that you will deliver things that are likely to meet your own needs at future stages of the development of the product.

This idea of velocity works against diversity in several ways. If we look at the psychological concepts related to groups and language, we can see that different groups have different languages (ways of thinking, ways of behaving), and that gap means that it is harder to communicate between groups than it is to communicate within groups. The natural shortsighted approach to speed up development progress in the short term is to mute some people whose inputs you do not understand or value. Muting has the effect of quashing the diversity of input into solutions but also makes it easier for the rest of the team to reach a consensus. However, trying to increase velocity naively in this way eventually will slow you down. This slowing down happens naturally due to 

• increased technical debt in the product or service code base,
• increased “cultural debt” – how your internal company culture affects your product development and how well your team works together, and 
• decreased representation of the types of people in your customer base on your development team, which affects the likelihood that your product or service to the types of customers no longer represented.

The more different people from different groups interact, the harder it is to communicate deeply, and the harder it is to reach any form of agreement. This difficulty slows down communication speed and hence also slows down product development in the short term. It takes practice and trust to overcome this problem, but the long-term dividends are worth it. A diverse team that has learned to bridge the communication gaps and work together well can be extremely creative and productive.

Assumption 4: People can always work at a constant pace

In addition to using velocity as a metric, Agile also has this notion that a team can work at a constant pace, and each of the individuals can contribute at a constant pace. The best teams find their pace and stay at it.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

– Agile Manifesto

This assumption often does not hold. Being able to do your job at a constant pace is a luxury. In general, it requires a stable living situation, a support group that allows you to go to work even when you have basic problems such as childcare or transportation, and the mental health to have the stamina to deliver results at a constant pace. Many people do not have these support systems. The canonical 1950s husband with the stay-at-home wife and the stable, lifetime job had significant support systems in place. People who have been raised with a comfortable income and have a financial buffer can gain some stability from that. Sad to say, in this modern world, many people do not have these support systems. Working mothers. Racial minorities. Autistic people. People with mental illness. Disabled people. Yet these are often the diverse people we want to attract to a diverse workplace.

If we are going to optimize our workforce to enable each person to contribute to the fullest, we need to deal with the fact that external circumstances impact the pace at which a person can work. The work bandwidth you see from them varies over time. There is no innate reason why someone who can give you 100% this month but nothing next month is any less productive than the person who can give you a steady 50%. Yet the former person becomes a problem, while the latter person is okay because they are predictable and help the team maintain a ‘constant pace’.

Reflecting back on metrics, then, there are better and more diversity-friendly metrics for productivity, ones which are tied more to the business objectives than to coding or tickets or burndown rates. For example, the features that the team is developing can be tied to business objectives, and team productivity tied to new features per quarter. This metric has the advantage of encouraging creativity and the development of new features, while disincentivizing developing them in a way that increases technical or cultural debt. Working collaboratively, using everyone’s strengths, helps the developers perform better against this metric as well. This metric, also, is calculated over quarters, not sprints – smoothing the way for some sprints to be less productive (for a variety of reasons), but enabling a focus on supporting faster execution on longer-term objectives.

Assumption 5: The best way to progress is incrementally

Agile assumes that the best way to get to a good solution and a good architecture is incrementally; that a good solution will emerge from incremental steps.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

– Agile Manifesto

Incremental progress leads to a focus on the short term, quicker conversations. “What are the next steps?” But often even when the end vision is clear and the requirements are not changing, different groups may see different paths to the end. One person may see a path that starts out being harder and with longer steps, but leads to a cleaner, more extensible and more intuitive implementation, while another person may see a path that starts out easier but the way the start happens leads to a less clean and extensible implementation. In any given situation, it is likely that the steps that are logical for one person are not logical from the point of view of some other person with different experiences and values.. For example, often the person who is a slower thinker, who deliberates many options, may see things that others don’t, but that affect the development of the product in intangible ways. However, the slower thinker may be unable to vocalize these concerns at the pace that the team is moving. This kind of situation is particularly true when something new is being developed and the path to a solution is not a well-trodden one.

When people come from different cultures and different perspectives, where their values of generalization vs specialization differ, where their notion of collaboration differs, and where there are different ideas on how the product or service should support a particular class of user  — these all impact what steps to start with as well as how to take the steps and in what order. Since these differences align with how people think, they also frequently align with the groups. That is, often there is a particular start path that is basically agreed on by the dominant group, and other paths that align more with the minority groups. One setting where this is evident is when you have an older, more experienced engineer working with younger, less experienced ones. The older person is likely to try to fold in concerns about maintainability and flexibility at an earlier stage of the development process. Another example occurs when you have a disabled engineer trying to include disability-friendliness into the project earlier. When one or the other group is muted, the initial steps taken in the process may preclude the very real long-term effects on product applicability, maintainability and durability that the muted person is trying to convey.

Assumption 6: The best solutions emerge organically

“The best architectures, requirements, and designs emerge from self-organizing teams.”

– Agile Manifesto

Because of its incremental nature and the mindset of being able to change your software and requirements early and often, there is an assumption that a good architecture and good products will emerge. Yet self-organization works well only when all of the team members are listening to each other and valuing each other’s input equally. However, as stated earlier, we tend to listen to and value the input of our own group above others. When one group dominates, the minority groups are often muted and unable to contribute things that would improve the architectures, requirements, and designs. In the long run, though, the dominant group does not retain the key to the best architecture, or the best requirements, or the best designs.

This muting of the minority groups has an impact in the longer term on the group composition. Because they are not listened to, the members of the minority groups are seen as not contributing to the architecture, requirements, and designs. As a result of their muting, they become less valuable to the group, and eventually the group ‘self-organizes’ them out. When a person is not listened to and is organized out, often the architectures, requirements, and designs are not as strong, creative, and durable as they would have been had the person’s input been considered more deeply.

Call to Action

Despite what I have said above, I do believe that Agile is a really good step forward in software development processes. I do appreciate not being trapped in the days of ever-changing requirements documents with little or no development time. Those were very discouraging and unproductive times.

So what is there to do next? How do we move forward from here? I would say, the answer is mostly in the who, not the how. Ask the groups who were muted because they were not represented in the original process of developing the Agile manifesto. Let them map a path of change from within.

One of the Agile strengths is that it bakes in time and space for reflection into the software development process.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

– Agile Manifesto

Reflection allows time and space for thinking and improvement. Now is a good time to apply these reflection principles to the Agile manifesto itself. 

This retrospective process is an exercise that should include all sorts of diverse members across the software development and Agile community. We need to listen to their stories. Where is it working well? What could be improved? Specifically, what aspects of Agile could be improved to facilitate the software and tech industry in the process of becoming more diverse, inclusive, and equitable? How can we open up the discussion to enable people in minority groups (gender, race, neurodiversity, disability, etc.) to speak for themselves about where improvements can be made, and to express concrete changes? How can we change the agile ceremonies, assumptions and metrics to ensure that all working and communication styles are accommodated and no voice is muted?

Learning to listen, understand and accept what everyone has to say despite our own biases is a key competence to develop and use throughout this retrospective process. This means looking at different modes through which underrepresented people can communicate their ideas and concerns. A second key element is understanding and embracing the long-term value of inclusion and diversity within software development. A third key element is developing the underlying mindset that diversity is a win-win proposition for all – a mindset that brings everyone to the table naturally.

Agile naturally incorporates the willingness to evolve and improve our processes. We already do this with our technical processes and our day-to-day working together, but we can expand this approach to improving our recognition that each person on the team as someone who belongs, has strengths and has unique contributions to make. Teams work best when all members work to communicate, understand and trust each other better, and where people work through their differences respectfully.

Listen. Value. Include. The Agile process inherently supports teamwork and evolution. In the spirit of Agile, it is time to do a deep meta-retrospective on the Agile manifesto and the processes and rhythms that derive from it.

[1] Griffin, Emory A (2011). A First Look at Communication Theory. New York: McGraw-Hill. ISBN978-0-07-353430-5.