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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
There’s even a Wikipedia page dedicated to software development failures<\/a>… and the list is far from complete because most failures are hidden from taxpayers and investors. Millions of dollars are wasted on projects eventually canceled.<\/p>\n Gamers know that big projects get endlessly delayed and canceled. Big software companies promise features that never arrive. Such is development.<\/p>\n 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.”<\/p>\n Agile software development embodies ableism at its unintentional naturalized worst.<\/strong><\/p>\n Sadly, the extroverts in project management have decided we must all be like them. They not only embraced extreme programming, they took the \u201cAgile Manifesto\u201d 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.<\/p>\n Agile exists in direct opposition to the natures of many Neurodiverse, talented developers.<\/strong><\/p>\n Let us be ourselves and we can do some amazing work. Try to change us? We won\u2019t remain on the team. Too often, we\u2019re bullied into masking, trying to be people we are not.<\/p>\n WARNING: THIS IS A LONG POST<\/strong><\/p>\n Agile software development comes in many flavors, with the big three being Scrum, XP, and Lean\/Kanban. I\u2019m going to use \u201cAgile\u201d generically, in place of its variations. I\u2019ve 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\u2019ve observed because they aren\u2019t inclusive of all personality types, disabilities, or Neurodiversity.<\/p>\n The Agile Manifesto, like so many manifestos, is vague and idealistic. The document isn\u2019t 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:<\/p>\n Manifesto for Agile Software Development<\/a><\/p>\n We are uncovering better ways of developing\u2028software by doing it and helping others do it.<\/p>\n Through this work we have come to value:<\/p>\n That is, while there is value in the items on \u2028the right, we value the items on the left more.<\/p><\/blockquote>\n All four points concern me as a disabled and Neurodiverse individual.<\/strong> 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 \u201citems on the right\u201d matter, it\u2019s usually a sign they won\u2019t matter enough.<\/p>\n \u201cInteractions\u201d leads to an emphasis on talking face-to-face, as I\u2019ll explore later. Also, the emphasis on people sounds good but often leads to all sorts of \u201cteam-building\u201d and \u201cteam nurturing\u201d practices that exclude people like me.<\/p>\n \u201cWorking software\u201d means something specific to me. I hated watching teams push out \u201cworking\u201d code that wasn\u2019t 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 \u201cworking code\u201d would insert pause after pause, tracing the current values in variables along the way towards a useful result.<\/p>\n \u201cCustomer collaboration\u201d 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 \u201ccustomer collaboration\u201d strategy.<\/p>\n And I don\u2019t know many Neurodiverse people who look forward to working without a plan. That\u2019s inviting disastrous meltdowns for some of us.<\/p>\n Autistics programmers might be gifted coders, but we\u2019re not social, hate incomplete and useless feedback, don\u2019t like collaboration sessions, and we need a plan. We need structured routines.<\/p>\n Agile cannot be ignored by disability advocates in technology.<\/strong> We have to deal with the problems the proponents of Agile consciously and unconsciously introduce into our chosen careers.<\/p>\n 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:<\/p>\n Let\u2019s start with the \u201cstand-up\u201d meetings because the obvious ableism cannot be dismissed by any thinking person. We\u2019ll get to the \u201cface-to-face\u201d because it\u2019s a special kind of hell \u2014 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.<\/p>\n Beginning the morning with a stand-up meeting that\u2019s \u201ctime blocked\u201d 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\u2019m not alone. If I\u2019m standing, I\u2019m pacing and moving constantly. I have a palsy, too, so the pain leads to tremors. What about people with other mobility challenges?<\/p>\n The person in a wheelchair isn\u2019t face-to-face with colleagues. That\u2019s insulting, a power imbalance. Someone with crutches or leg braces? A severe back injury?<\/p>\n The stand-up meeting draws unnecessary attention to differences and is in direct opposition to the theory of natural accommodations.<\/strong><\/p>\n Since the meetings are limited to 15 minutes, people speak quickly. I\u2019m all for quick meetings, but as a Neurodiverse individual spoken language gets jumbled in my mind and I don\u2019t 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?<\/p>\n Fast-paced discussions exclude anyone with a hearing or auditory processing difference.\u00a0<\/strong>Once again, the stand-up meeting excludes differences and acts as an exclusionary practice.<\/p>\n Face-to-face meetings might not be as bad as a 15-minute standing rapid-fire session, but they\u2019re not much better. Policies that suggest face-to-face meetings are inherently \u201cbetter\u201d or \u201csuperior\u201d 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.<\/p>\n Again, the Neurodiverse? Sorry, but you must be inferior since you miss those non-verbal cues, speech signals, and social markers. And if you\u2019re more confused after a face-to-face meeting, that\u2019s a deficiency with you, not the meeting strategy.<\/p>\n 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, \u201cReading lips isn\u2019t some perfect, magical skill, especially when there are four or five people talking!”<\/p>\n 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.<\/p>\n And, no, video chats with captions aren\u2019t direct replacements for face-to-face. They\u2019re just as draining and often even more difficult to follow.<\/p>\n People do not function on two-week cycles, a common approach to \u201csprint\u201d 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.<\/p>\n The Agile Manifesto creators did not insist on two-week cycles for development. <\/strong>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.<\/p>\n In the actual \u201cPrinciples\u201d 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.<\/p>\n Sprints are unhealthy for most people and abusive towards the Neurodiverse.<\/strong>\u00a0Programming requires a lot of mental energy. If I \u201csprint\u201d through a few nights of coding when I\u2019m at full-throttle, I need days to recover. Neurodiverse coders I know have the same need: burst, rest, prepare\u2026 burst again. That\u2019s not a cycle project managers seem to grasp.<\/p>\n 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.<\/p>\n Agile project managers argue, \u201cWe understand the need for balance! It\u2019s part of our philosophy.\u201d Yeah, but I haven\u2019t seen that in practice.<\/p>\n Catering lunches and providing game rooms isn\u2019t balancing the work-life scales. No. Those \u201cbenefits\u201d merely serve to keep developers at work week after week after week. The sprints become a marathon. I\u2019ve observed this too often for it to be an isolated problem.<\/p>\n 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.<\/p>\n I\u2019ve 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.<\/p>\n If your employees are actively trying to cope with your floor plan, it\u2019s a bad design.<\/strong><\/p>\n We\u2019ve known for years that the open floor plan did not enhance productivity. It does not encourage \u201cosmosis\u201d learning, either, regardless of the claims made by some Agile consultants. Stop defending what research suggests makes workers unhappy and unproductive.<\/p>\n Open floor plans create and exacerbate sensory distractions.\u00a0Neurodiverse employees need control over their spaces to limit sensory overload.<\/strong><\/p>\n My sensory needs are not the needs of others.<\/strong> That\u2019s why we each need some control over our workspaces. Personally, I need dimmer lights with a blueish tint \u00a0(5000 Kelvin and above). Other Neurodiverse individuals respond poorly to blue lighting and want the \u201cwarmer\u201d yellows (3000-4000 Kelvin).<\/p>\n My body doesn\u2019t control its temperature well; my palsy and other physical conditions limit the body\u2019s 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.<\/p>\n There are other challenges, too. Many open plans feature moving desks, mobile carts of various kinds, and other obstacles. Don\u2019t rearrange my spaces. That\u2019s not good for my visual memory.\u00a0A 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\u2019t quickly dart over to an impromptu meeting, the meeting will come to you.<\/p>\n 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\u2019d 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.<\/p>\n This worked well, having two people examine all code and documents. I\u2019m all for extra \u201ceyes\u201d on code and text. We all need editors.<\/p>\n 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\u2019t like this at all. I hate it, and I\u2019m not alone.<\/p>\n \u201cThings go faster working together!\u201d the Agile consultants claim. \u201cIt reduces the person-days.\u201d What the heck is a person day? Those mythical internal billing days of human time?\u00a0\u201cPerson days\u201d don\u2019t exist. They\u2019re right there with the Mythical Man-Month.<\/p>\n \u201cJust put on headphones and ignore the person is there,\u201d I\u2019ve been told. Then just don\u2019t put the person next to me in the first place. And it isn\u2019t as if I can block out the presence of a human.<\/p>\n It\u2019s bad enough to meet with people face-to-face, but I cannot stand and will not tolerate someone within my space.<\/strong> I hear the person breathing. I smell everything. The mere proximity causes anxiety. If that person is a \u201csnacker\u201d or, worse, a \u201ctalker,\u201d I am not going to be able to function.<\/p>\n Do not confuse sitting with a \u201cpartner\u201d 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. <\/strong>\u00a0I prefer my space, and I\u2019m still productive in that space.<\/p>\n 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\u2019ve never met my current editorial team and I have not talked to them by voice or video conference. We don\u2019t need to interact in real-time.<\/p>\n My wife has telecommuted since 2011. She has colleagues around the globe. They collaborate, but they certainly don\u2019t need to sit together.<\/p>\n 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 \u201calways available\u201d modes of contact, as if all that multitasking doesn\u2019t impede productivity.<\/p>\n If you insist I answer emails and messages within a time window, you won\u2019t have me as an employee for long.<\/p>\n Nobody multitasks well, and instant communication disrupts thoughts and requires\u00a0\u2018recovery\u2019 time.<\/strong> 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.<\/p>\n Read A World Without Email: Reimagining Work in an Age of Communication Overload<\/a> by\u00a0Cal Newport \u00a0(2021). You should also read his 2016 text, Deep Work: Rules for Focused Success in a Distracted World<\/a>.<\/p>\n Demanding rapid response times is another form of ableism.\u00a0<\/strong>If all workers struggle to refocus after checking email and messages, try to understand the challenges for Neurodiverse workers. Setting foolish guidelines (and I\u2019ve lived with these) such as \u201cRespond within 30 minutes to all messages during the workday\u201d are detrimental to morale and productivity. The team member with ADHD already has to cope with email, messages, and probably vibrating phone alerts.<\/p>\n We know that email and messages were designed for Pavlovian responses. The little badges, the alerts, the tones, all compel us to react.<\/p>\n Agile wasn\u2019t meant to be about non-stop connections to others, but that\u2019s what it too often becomes. I\u2019m turning off Slack, Teams, and email alerts when I\u2019m deep into a task. We survived for centuries without instant responses to messages. If you value my skills, let me work in peace.<\/strong><\/p>\n Too many Agile \u201cexperts\u201d recommend skipping important documentation procedures. Commenting code? Takes too long. After all, good code should be clear code, right? (That\u2019s rarely true in reality.) User documentation? Nobody reads it anyway. Even the writing suggested by Agile methods ends up being shortchanged. User stories? Let\u2019s just bullet point those.<\/p>\n Agile proponents correctly identified useless documentation as a drain on projects. However, the response should not be to neglect valuable documentation.\u00a0I encourage you to read Agile Insider\u2019s post\u00a0Agile Bullshit:\u00a0There is no documentation in Agile Software Development<\/a><\/p>\n The ideal Agile team documents code and creates a documented standard for \u201ccomplete\u201d phases of development. Yet. \u201cWe\u2019ll know it when we see it\u201d has become commonplace within Agile software development.<\/p>\n Code without documentation is a nightmare to update. Incomplete user documentation creates usability problems. Skimping on documentation in the name of \u201cefficiency\u201d will only cost time in the future.<\/p>\n A lack of clear objectives heightens anxiety for Neurodiverse individuals.<\/strong> 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.\u00a0Anything that might affect our employment should be in writing.<\/strong><\/p>\n Someone evaluates the team members. You owe it to the team to have clear expectations and these are the \u201ccontract\u201d items to which employees (and supervisors) should be held. If something isn\u2019t in writing and if all parties haven\u2019t had a chance to review that requirement, it doesn\u2019t exist.<\/p>\n Agile software development began as a set of good ideas. In practice, \u201cdoing Agile\u201d often represents the worst ableist assumptions of what \u201cnormal\u201d employees should be willing and able to do. Agile has come to emphasize physical mobility, in-person communication, shared workspaces, and social skills.<\/p>\n 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.<\/p>\n Agile practices need to evolve. I\u2019d also argue that the Era of Agile is coming to a close thanks to Big Data and projects that don\u2019t fit the agile model.<\/p>\n The disabled won\u2019t be mourning the end of Agile. We\u2019ll be too concerned that the next trendy project management practices might be worse.<\/p>\n Agile in practice isn\u2019t what Agile was meant to be. It\u2019s the implementations that made it a nightmare for people like me.<\/p>\n The stated principles associated with the Agile Manifesto are interesting, but not without some problems. For example, most contracts for software have a clear termination. There\u2019s a point at which the software is \u201cdone\u201d and the contract has been fulfilled. If a game ships on a cartridge, on a disc, or another medium, you cannot commit to regular updates, either.<\/p>\n Agile is best for in-house development, web-based solutions, or subscription models (software as a service). Otherwise, at least half the principles do not apply to projects, which are seldom \u201cindefinite\u201d in scope.<\/p>\n Here are the stated principles:<\/p>\nAgile Development Ideals<\/strong><\/h3>\n
\n
The Disabled versus \u2018Agile\u2019 in Practice<\/h3>\n
\n
The Stand-Up Meeting<\/h3>\n
Face-to-Face Communication<\/h3>\n
Sprints and Other Races<\/h3>\n
Open Floor Plans<\/h3>\n
Pair Programming<\/h3>\n
Invasive Messaging Apps<\/h3>\n
Neglected Documentation<\/h3>\n
Agile in Practice Must Change<\/h3>\n
What the Agile Manifesto Authors Wrote<\/h3>\n