Press "Enter" to skip to content

Agile Development: Ableist Extroverts Setting Agendas

Last updated on November 26, 2023

I used to consider software development one of the few careers, outside librarians and medical examiners, surely insulated from the extroverts too often in charge of human society. Then, along came various project management schemes that forced programmers to act like extroverts.

This post discusses Agile software development project management theories and practices. It helps to understand why private and public companies rush from one trendy project management methodology to the next.

Most software development projects end in failure. Not little failures, either, but big expensive failures. Updating or creating a local government website. Upgrading ancient payroll systems. Creating a new online retail system. It doesn’t matter if it’s public or private, a majority of new systems are never delivered as envisioned.

There’s even a Wikipedia page dedicated to software development failures… and the list is far from complete because most failures are hidden from taxpayers and investors.

Gamers know that big projects get endlessly delayed and canceled. Big software companies promise features that never arrive. Such is development.

Over time, names were given to development methodologies. Waterfall. Contract. Function Delivery. Along came eXtreme Programming (XP) and Lean. These last two were grouped with a broad project management philosophy known as “Agile Software Development.”

Agile software development embodies ableism at its unintentional naturalized worst.

Sadly, the extroverts in project management have decided we must all be like them. They not only embraced extreme programming, they took the “Agile Manifesto” and turned it into the basis for project management certifications. The Project Management Institute will gladly charge you a small fee for the honor of taking an exam leading to the Agile Certified Practitioner title.

Agile exists in direct opposition to the natures of many Neurodiverse, talented developers.

Let us be ourselves and we can do some amazing work. Try to change us? We won’t remain on the team. Too often, we’re bullied into masking, trying to be people we are not.

Agile Development Ideals

Agile software development comes in many flavors, with the big three being Scrum, XP, and Lean/Kanban. I’m going to use “Agile” generically, in place of its variations. I’ve been directly exposed to eXtreme Programming and Scrum, which is what most people mean when they discuss Agile. I have problems with the two Agile approaches I’ve observed because they aren’t inclusive of all personality types, disabilities, or Neurodiversity.

The Agile Manifesto, like so many manifestos, is vague and idealistic. The document isn’t good or bad, but it does support the able-bodies extroverted version of Agile in practice. It is the implementation of Agile that makes it ableist. Consider the manifesto:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • 
Responding to change over following a plan

That is, while there is value in the items on 
the right, we value the items on the left more.

All four points concern me as a disabled and Neurodiverse individual. The nuance that all the items matter, the Agile philosophy merely weighs one side more than the other, is a nuance ignored in practice. When a manager or lead keeps telling me that the “items on the right” matter, it’s usually a sign they won’t matter enough.

“Interactions” leads to an emphasis on talking face-to-face, as I’ll explore later. Also, the emphasis on people sounds good but often leads to all sorts of “team-building” and “team nurturing” practices that exclude people like me.

“Working software” means something specific to me. I hated watching teams push out “working” code that wasn’t useful and would have to be discarded along the way. In financial modeling, you might enter thousands of variables and then just wait (and wait) for a few numbers in return. There are few, if any, meaningful mid-step functions. Yet, teams trying to demonstrate “working code” would insert pause after pause, tracing the current values in variables along the way towards a useful result.

“Customer collaboration” should not include me during any in-person meetings, not even in the same room. My blunt, honest nature needs a filter. Yes, there are ways to accommodate the Neurodiverse, but those are rarely part of the “customer collaboration” strategy.

And I don’t know many Neurodiverse people who look forward to working without a plan. That’s inviting disastrous meltdowns for some of us.

The Disabled versus ‘Agile’ in Practice

Autistics programmers might be gifted coders, but we’re not social, hate incomplete and useless feedback, don’t like collaboration sessions, and we need a plan. We need structured routines.

Agile cannot be ignored by disability advocates in technology. We have to deal with the problems the proponents of Agile consciously and unconsciously introduce into our chosen careers.

Problems with Agile software development for the disabled and Neurodiverse are in the implementations of Agile. None of these practices are required by the Agile Manifesto itself. However, in an Agile office, you will experience some or all of these:

  • Stand-up meetings to encourage speed and brevity.
  • Face-to-face conversation favored over other discussions.
  • Sprint calendars, with fixed timelines, to expedite working modules.
  • Desks sitting together in “open” floor plans for “osmosis” learning.
  • Pair programming (XP) to “fix” the flaws of single-coder models.
  • Always-on chat models for “working agreements” and feedback loops.
  • Documentation subordinated to focus on “finished” projects.

The Stand-Up Meeting

Let’s start with the “stand-up” meetings, because the obvious ableism cannot be dismissed by any thinking person. We’ll get to the “face-to-face” because it’s a special kind of hell — and the stand-up meeting is part of that. The stand-up has a lot of other issues all in one massive ball of miserable ableism.

Beginning the morning with a stand-up meeting that’s “time blocked” to 15 minutes could only sound like a good idea to an able-bodied extrovert. Standing in one place for 15 minutes causes extreme pain for me, and I’m not alone. If I’m standing, I’m pacing and moving constantly. I have a palsy, too, so the pain leads to tremors. What about people with other mobility challenges?

The person in a wheelchair isn’t face-to-face with colleagues. That’s insulting, a power imbalance. Someone with crutches or leg braces? A severe back injury?

The stand-up meeting draws unnecessary attention to differences and is in direct opposition to the theory of natural accommodations.

Since the meetings are limited to 15 minutes, people speak quickly. I’m all for quick meetings, but as a Neurodiverse individual spoken language gets jumbled in my mind and I don’t remember it well at all. I process language slow and need time to untangle the words. What about someone who is Deaf or has a hearing impairment? What about non-native speakers of the language?

Fast-paced discussions exclude anyone with a hearing or auditory processing difference. Once again, the stand-up meeting excludes differences and acts as an exclusionary practice.

Face-to-Face Communication

Face-to-face meetings might not be as bad as a 15-minute standing rapid-fire session, but they’re not much better. Policies that suggest face-to-face meetings are inherently “better” or “superior” tend to reference theories on non-verbal cues, vocal tone, and social connection. These policies also emphasize that, unlike email or discussion systems, face-to-face meetings end with some level of closure and agreement.

Again, the Neurodiverse? Sorry, but you must be inferior since you miss those non-verbal cues, speech signals, and social markers. And if you’re more confused after a face-to-face meeting, that’s a deficiency with you, not the meeting strategy.

My Deaf colleagues have told managers and human resource departments that written policies promoting face-to-face communication as the ideal are ableist. Often these colleagues need note-takers, sign language translators, or other supports. As one Deaf colleague messaged me, “Reading lips isn’t some perfect, magical skill, especially when there are four or five people talking!”

For some of us, email is better. Text-based messages are also (slightly) better than face-to-face, assuming colleagues can wait patiently for replies.

And, no, video chats with captions aren’t direct replacements for face-to-face. They’re just as draining and often even more difficult to follow.

Sprints and Other Races

People do not function on two-week cycles, a common approach to “sprint” programming cycles. The Neurodiverse? We definitely do not function on two-week cycles. Whether autistic or ADHD (and often both), our cycles range from full-throttle to burnout, with no particular calendar alignment.

The Agile Manifesto creators did not insist on two-week cycles for development. The two-week sprint model has been imposed by project managers who like their own fixed routines as crutches. The reality is, the two-week cycles lead to rushed, sloppy code and the withdrawing or shifting of features simply to make milestone release dates.

In the actual “Principles” document included alongside the Agile Manifesto, the authors argued for weeks or months (as opposed to years) and suggested targeting narrow release windows. However, they did not suggest a fixed every-two-week calendar.

Sprints are unhealthy for most people and abusive towards the Neurodiverse. Programming requires a lot of mental energy. If I “sprint” through a few nights of coding when I’m at full-throttle, I need days to recover. Neurodiverse coders I know have the same need: burst, rest, prepare… burst again. That’s not a cycle project managers seem to grasp.

Where are the programmers who can work eight or nine hours, stop cold, and go home? Who are these people? Superimpose a two-week calendar on the programmers I know and you end up with the horrible 80-hour weeks that burn out everyone and result in resentment.

Agile project managers argue, “We understand the need for balance! It’s part of our philosophy.” Yeah, but I haven’t seen that in practice.

Catering lunches and providing game rooms isn’t balancing the work-life scales. No. Those “benefits” merely serve to keep developers at work week after week after week. The sprints become a marathon. I’ve observed this too often for it to be an isolated problem.

The Neurodiverse might work well for two or three days and then need a mental health day. We might design and code for a solid week. However, we will burn out and then need downtime.

Open Floor Plans

I’ve toured software companies with massive open spaces, echoing loudly with the clicks of mechanical keyboards. Most of the employees in the spaces wore headphones (with microphones) and many were wearing sunglasses.

If your employees are actively trying to cope with your floor plan, it’s a bad design.

We’ve known for years that the open floor plan did not enhance productivity. It does not encourage “osmosis” learning, either, regardless of the claims made by some Agile consultants. Stop defending what research suggests makes workers unhappy and unproductive.

Open floor plans create and exacerbate sensory distractions. Neurodiverse employees need control over their spaces to limit sensory overload.

My sensory needs are not the needs of others. That’s why we each need some control over our workspaces. Personally, I need dimmer lights with a blueish tint  (5000 Kelvin and above). Other Neurodiverse individuals respond poorly to blue lighting and want the “warmer” yellows (3000-4000 Kelvin).

My body doesn’t control its temperature well; my palsy and other physical conditions limit the body’s ability to regulate temperature normally. I sweat a lot over 72 degrees Fahrenheit, while others might be comfortable at 80 degrees. I cannot wear a dress shirt, tie, and jacket without overheating. In an open floor plan, without an office space, I struggle with the temperature of workspaces.

There are other challenges, too. Many open plans feature moving desks, mobile carts of various kinds, and other obstacles. Don’t rearrange my spaces. That’s not good for my visual memory. A Blind colleague noted that everyone found going to her desk was easier than asking her to navigate the ever-changing spaces of an open floor plan. Those with mobility challenges might have similar experiences. If you can’t quickly dart over to an impromptu meeting, the meeting will come to you.

Pair Programming

When I was coding and writing documentation at a university computing center, many years ago, the manager used pairs. This worked well because we traded off the documents and the code electronically. You’d send an email to the teammate and update a shared checklist to show that you had completed your task. Sometimes, you were the initial programmer or writer, sometimes you were the editor.

This worked well, having two people examine all code and documents. I’m all for extra “eyes” on code and text. We all need editors.

But, Agile proponents often argue for people sitting side-by-side and taking turns at the same keyboard, looking at the same screens. No. I don’t like this at all. I hate it, and I’m not alone.

“Things go faster working together!” the Agile consultants claim. “It reduces the person-days.” What the heck is a person day? Those mythical internal billing days of human time? “Person days” don’t exist. They’re right there with the Mythical Man-Month.

“Just put on headphones and ignore the person is there,” I’ve been told. Then just don’t put the person next to me in the first place. And it isn’t as if I can block out the presence of a human.

It’s bad enough to meet with people face-to-face, but I cannot stand and will not tolerate someone within my space. I hear the person breathing. I smell everything. The mere proximity causes anxiety. If that person is a “snacker” or, worse, a “talker,” I am not going to be able to function.

Do not confuse sitting with a “partner” for collaborating on a project or product. I do not want a partner. I did not want them in school and I definitely do not want them at work.  I prefer my space, and I’m still productive in that space.

I write for a magazine and have since 2006. Any publication is a group effort with writers, copyeditors, section editors, artists, and so on. I receive assignments and email my editors with ideas. I write as part of a larger team, but while I am writing I sit alone at home. I’ve never met my current editorial team and I have not talked to them by voice or video conference. We don’t need to interact in real-time.

My wife has telecommuted since 2011. She has colleagues around the globe. They collaborate, but they certainly don’t need to sit together.

Invasive Messaging Apps

Agile proponents miss something their own mystical gurus said: give developers the space and peace necessary. Turning off messaging and ignoring email fits within the original Agile practices. Yet, some Agile consultants insist on “always available” modes of contact, as if all that multitasking doesn’t impede productivity.

If you insist I answer emails and messages within a time window, you won’t have me as an employee for long.

Nobody multitasks well, and instant communication disrupts thoughts and requires ‘recovery’ time. Too much research on email and instant messaging exists to ignore. Workers check email too often as it is, wasting valuable mental energy trying to prove their dedication to the team. Tools like Slack and Teams demand even quicker responses, draining more energy.

Read A World Without Email: Reimagining Work in an Age of Communication Overload by Cal Newport  (2021). You should also read his 2016 text, Deep Work: Rules for Focused Success in a Distracted World.

Demanding rapid response times is another form of ableism. If all workers struggle to refocus after checking email and messages, try to understand the challenges for Neurodiverse workers. Setting foolish guidelines (and I’ve lived with these) such as “Respond within 30 minutes to all messages during the workday” are detrimental to morale and productivity. The team member with ADHD already has to cope with email, messages, and probably vibrating phone alerts.

We know that email and messages were designed for Pavlovian responses. The little badges, the alerts, the tones, all compel us to react.

Agile wasn’t meant to be about non-stop connections to others, but that’s what it too often becomes. I’m turning off Slack, Teams, and email alerts when I’m deep into a task. We survived for centuries without instant responses to messages. If you value my skills, let me work in peace.

Neglected Documentation

Too many Agile “experts” recommend skipping important documentation procedures. Commenting code? Takes too long. After all, good code should be clear code, right? (That’s rarely true in reality.) User documentation? Nobody reads it anyway. Even the writing suggested by Agile methods ends up being shortchanged. User stories? Let’s just bullet point those.

Agile proponents correctly identified useless documentation as a drain on projects. However, the response should not be to neglect valuable documentation. I encourage you to read Agile Insider’s post Agile Bullshit: There is no documentation in Agile Software Development

The ideal Agile team documents code and creates a documented standard for “complete” phases of development. Yet. “We’ll know it when we see it” has become commonplace within Agile software development.

Code without documentation is a nightmare to update. Incomplete user documentation creates usability problems. Skimping on documentation in the name of “efficiency” will only cost time in the future.

A lack of clear objectives heightens anxiety for Neurodiverse individuals. Disabled people in general have been abused by supervisors with vague expectations and unclear standards. Too often supervisors review us poorly for not meeting an expectation or goal that was never put in writing. Anything that might affect our employment should be in writing.

Someone evaluates the team members. You owe it to the team to have clear expectations and these are the “contract” items to which employees (and supervisors) should be held. If something isn’t in writing and if all parties haven’t had a chance to review that requirement, it doesn’t exist.

Agile in Practice Must Change

Agile software development began as a set of good ideas. In practice, “doing Agile” often represents the worst ableist assumptions of what “normal” employees should be willing and able to do. Agile has come to emphasize physical mobility, in-person communication, shared workspaces, and social skills.

I have met too many good, even great, Neurodiverse software developers who walked away from Agile teams and employers. I know Deaf and Blind programmers and designers who found Agile too frustrating to endure for more than a year or two.

Agile practices need to evolve. I’d also argue that the Era of Agile is coming to a close thanks to Big Data and projects that don’t fit the agile model.

Agile in practice isn’t what Agile was meant to be. It’s the implementations that made it a nightmare for people like me.

The disabled won’t be mourning the end of Agile. We’ll be too concerned that the next trendy project management practices might be worse.

Discover more from The Autistic Me

Subscribe now to keep reading and get access to the full archive.

Continue reading