We—consultant engineers at Stride, that is—are agilists. When we arrive at clients’ sites, we recommend building software using agile methodologies and extreme programming (XP) practices. We build software in that particular way because we want high-quality code, strong relationships, and successful delivery of projects. But that’s not the only impact of using agile and XP.
I’ll be talking about a particular unexpected effect of doing things that way, which is that it helps me manage my ADHD. I think if we know more about how a variety of brains succeed in building things together, we’ll be better able to accommodate for differences.
What is ADHD?
ADHD stands for Attention-Deficit/Hyperactivity Disorder. Originally it was called hyperkinetic impulse disorder, and then ADD (Attention Deficit Disorder), and then ADD with hyperactivity as a subtype. The official name is now ADHD, with three subtypes (Primarily Inattentive, Primarily Hyperactive-Impulsive, or Combined).
Before I was diagnosed, I believed the common stereotype of a person with ADHD—namely, they’re a young boy who cannot sit still in class and gets easily distracted. That is not really the whole picture. I, for example, am an adult woman who was very much able to sit still in class. Turns out I have ADHD.
To describe it in terms of brain chemistry, ADHD is the collection of behavioral effects of releasing a below-average amount of dopamine (I am not a doctor or scientist, so this is a broad interpretation). And, of course, it expresses itself differently in different people.
What does it look like in me?
I spent a really long time not knowing I had ADHD. I thought because I could sometimes focus that I wasn’t hyperactive, and because I was good at school that I was basically managing well enough. I also didn’t know that when people said they hated going to the bank they didn’t mean they literally…couldn’t…go to the bank.
I’ve yelled at myself before for being lazy, forgetful, disorganized, paralyzed, etc., but it didn’t work to get me to actually do things. Now that I have the diagnosis, I spend a little more time non-judgmentally assessing why I’m not doing things. And it’s often easy enough to solve, if you let go of how you’re “supposed” to do it.
To me, ADHD doesn’t feel like a deficit of attention. I have an abundance of attention. I will spend 50 hours gluing beads, without interruption. Instead it feels more like a failure of “executive function,” where I have trouble prioritizing, initiating tasks, or problem-solving small issues when I’m doing a multi-step process.
Note on the bias of diagnosis
A “disorder” or a “disability” is defined because a system defines you as disruptive to it. This is called the social model of disability, and you can read more about it in “Rethinking disability: the social model of disability and chronic disease,” by Sara Goering. In summary, physical or psychological variations may cause individual impairments, but those impairments do not necessarily lead to disability unless society is structured to exclude them.
So though ADHD is called a “disorder,” that is an exclusionary bias that unfairly asks all brains to work the same way. I think ADHD is a reasonable genetic variation in the population that helps the human race, and if I were in a different context where I was mostly responsible for gluing beads to things, it would never come up that I can’t go to the bank.
Instead, most of what we have to be good at in contemporary American life requires executive functioning, and it’s just not my skill set, so I’m said to have a “disorder.” I think that’s unfair, but I still have to live here, so I’ve figured out some workarounds.
Finding a system that works for me
As I’ve learned more about how I’ve coped with ADHD without knowing I had it, I’ve realized that the way we build software is extremely effective for me! Without consciously meaning to, I’ve found my way into a career and methodology that gives me tools for what I lack (executive functioning) and takes advantage of my special skills (emotions and math).
Executive functioning takes a lot of energy, even if you don’t have ADHD. In a way, agile software development was invented to manage executive functioning failure at a project level!
Early agilists saw that software projects often failed, so they introduced powerful tools that reduced huge, unapproachable deadlines; put stakeholders in collaboration with each other; and made projects resilient to changing requirements. And extreme programming extends those tools to engineering practice, doubling down on accountability and communication.
By sharing the executive functioning for the group, agile and XP reduce the amount of executive functioning each individual needs to do. And this helps everyone, especially me.
Here’s a list of questions that require executive functioning to answer
- What work do you have to do?
- What priority order should that work be in?
- How should you break up the big work into small pieces of work?
- How can you stop intending to do something and actually do it?
- How do you stay focused on the most important task?
And for each one, there’s a software practice! Let’s go through them.
What work do you have to do?
Sprints! User stories! Releases! Project-management tools!
When I’ve tried to use these tools on my own for personal projects, I’ve been so overwhelmed by the executive functioning it requires that I’ve abandoned ship. To-do list items languish and then disappear off the face of the earth.
But when shared by the team, revisited every day in a built-in meeting that everyone has to attend, the tools become reliable records of things we’re really planning to do. Then we do them! It’s heaven. When I first learned what Jira was and that everyone was going to help me use it, I was elated. I still love Jira. Don’t @ me.
What priority order should that work be in?
Sprint reviews! Cross functional teams! Stakeholders! Product Managers!
There’s a meeting for that. There’s an entire job for that! Product managers are executive functioning angels. I used to do that job, somehow. The only thing that worked for me was the constant interruption and problem-solving emergencies.
How should you break up the big work into small pieces of work?
Outside-in testing! TDD! Incremental changes, small commits, small PRs!
Bless outside-in testing, with its built-in checklist and breadcrumbs. Bless test-driven development, with its digestible units, one thing at a time. Bless all the ways good engineers make incremental changes, small commits, and small PRs, so that no one has to hold too much in their head at once. Multi-step processes are a classic enemy of people with ADHD. XP gives enough scaffolding that the path is clear enough to proceed.
How can you stop intending to do something and actually do it?
Working software! MVPs! Continuous integration! Small releases!
So many things in regular life are hard for me because I’m not sure exactly when to start. I am often deciding between doing something right this second or...never. A lot of things fall to never. That’s especially true when something is Very Important. Raising the stakes basically works to immobilize me from proceeding.
Agile’s focus on working software and MVPs is such a perfect antidote for this—something small, ugly, and working is better than something gorgeous and theoretical. Other XP practices such as continuous integration and small releases keep the team focused on reality, rather than on some Enormous Important Project that will always be too anxiety-producing to ever really deliver.
How do you stay focused on the most important task?
It’s time to talk about the most incredible innovation for ADHD ever created: Pair Programming. It’s good for all sorts of software quality and context-sharing reasons, but I like it because it basically solves my ADHD at work.
Actually...it’s weirdly similar to an “official” ADHD coping mechanism that healthcare professionals recommend, called “body doubling.” In an ADHD context, body doubling is asking another person to sit by you to help you complete tasks. It’s such a coincidence that I was trying to figure out whether that was on purpose. I’m still not sure—someone ask Kent Beck and Ward Cunningham!
Having another person there to hold me accountable for tasks eliminates procrastination, for me. When we take a break, I know they’re waiting for me at the end of five minutes. And pair-programming has the added benefit of needing you to rely on other people to make things work, which is humane and counter-cultural and fun.
Agile and XP are mechanisms that try to get things done by accounting for our humanity. When you do that, you end up including a lot of tools that help a broader group of people.
And in your own workplace, consider how you include people who work differently from you. Let’s say you observe someone unable to accomplish a task the way you would. Do you dismiss them as unreliable, or do you investigate what’s really blocking them? What if you could get the outcome you wanted, but they didn’t do it in the “right” way?
I feel that the way my brain is wired requires that I rely on other people. We worship individuality and heroics in our culture, but it just doesn’t work for me. Far from that being a disorder though, I think it’s what makes my life good. Thanks for living it with me!