Sarah MeiVerified account

When I first did real (small-a) agile, at @pivotallabs circa 2009, it was clear to me almost immediately that this was the most powerful way to build software that I’d ever participated in.

Pivotal wasn’t a brand so much at that point, and agile hadn’t “won.” I frequently had to explain, discuss, and (ultimately) defend the practices to many of the client developers on my early projects.

By the time I left Pivotal circa 2012, agile had crossed the chasm. Client developers no longer pushed back against the practices - and hadn’t for years, actually.

What practices are we talking about? 100% pair programming. 100% TDD. One week iterations. Daily pair rotation. Standups every day. Planning meetings and retrospectives once a week. And a fixed 9-6 weekday-only schedule to avoid burnout.

Pivotal took a page directly from the XP (eXtreme Programming) workbook. Their CEO, Rob Mee, had worked with some of the signatories on early agile projects, and had been putting it all into practice continuously since then.

I *loved* working like this. Agile is basically a set of attention hacks for me. For example - when I’m pairing I’m not on Twitter or email - all I’m thinking about is the problem at hand. Devs at Pivotal paired 8 hours every weekday, modulo standups, planning meetings, & retros.

I’d never worked in a way that seemed so likely to produce the _right_ product. That’s the motivator for me - building things that are useful and get used. I’m not motivated by the act of writing code (tedious, error prone) nor by new technology (unless the payoff is clear).

The agile/XP/Pivotal way of working is not without its issues. But the positives were so strong, relative to my previous experience, that it took me 5 years doing full-on agile to even start to see & articulate & connect the problems.

So let’s start with the obvious issues: - Very few people can pair that much. My job was essentially talking for 8 hours a day. - Many people can’t do a 9-6 fixed schedule. Parents, in particular, because no daycare place stays open past 6. This is ultimately why I left Pivotal.

- Many people have motivators that don’t mesh well with this system, including pushing frontiers via more research-y code, being in solo ‘flow,’ & using new technology. - Full-time pairing is hard across time zones. Having everyone in the same time zone is often unrealistic.

That’s the obvious stuff. Most of it can be solved by employing small-a agile, rather than a program like scrum or XP, so that the process adapts to the needs of the team.

The way I usually approach this is to have folks articulate what they’re trying to get out of a practice that’s not working for them. Then we brainstorm other practices that might have the same effect AND work better for that group. I’ll give you a quick example.

When people do pair programming, their goals are usually some subset of these: - focus - avoiding silos - code review - onboarding - cross-training - fewer rabbit holes There are other ways to get all those things.

So far, these are just the garden-variety problems with agile adoption that everyone’s been talking about for years. Let’s move on to the less-obvious problems.

To find agile's non-obvious problems, so we can start to see why heterogenous teams have trouble, let's take a peek underneath the surface of the obvious problems. Let's start with "very few people can pair that much."

For many years, I was a pair programming evangelist. Between that & my consulting work, I've met lots of people who tried pair programming and hated it. Some of them had paired for months, with different people, on different schedules, & still couldn't find a modality they liked.

These people came from many different genders & races. Some were introverted; some weren't. What they all had in common wasn't obvious to me for a long time...until recently, it was. They're all usually on the downward side of one or more _power dynamics_ in their pairs.

Power dynamics in pairing is a subject that rarely comes up, at either the macro (community discussion) or micro (team discussion) levels. First let's talk about what a power dynamic is, and then we can look at how it manifests in a pair.

A power dynamic is behavior in an interaction driven by a hierarchical relationship between the participants. This hierarchical relationship can be formal (manager-report, or senior-junior) but more often is informal (based on race, gender, background, etc.).

Informal power dynamics based on characteristics that have historically been subject to structural oppression turn around & mimic that structural hierarchy. Men are more powerful than other genders; white people are more powerful than other races. And so forth.

Note that "more powerful" in this context doesn't mean any kind of formal power; men are not officially more powerful than other genders. The power I'm talking about here is simply the power to _ignore the dynamic completely_.

People on the upward side of a power dynamic are free to pretend the dynamic doesn't exist, and indeed, many times as children they're told that that's what they should do. "Don't see color! Don't see gender!"

Even as adults, we get messages that sometimes suggest ignoring power dynamics is the right way to go. For example, I often see women asking men to treat them the same way that they, the men, treat other men at work.

The trouble with ignoring a power dynamic when you're on the upward side is that in doing so, you _reinforce_ the dynamic, even though in many situations (like pair programming) neutralizing it would be better.

That's because from the upward side, you need to take real action to level the playing field. Due to the inherent nature of these power dynamics, folks on the upward side have do it. They are more powerful & better resourced, and IMO it is their moral responsibility.

When you're on the upward side of a power imbalance & you want to level the field, ignoring (or denying) the tilt doesn't work. And if you place the burden on the downward side folks, you're asking them to both walk uphill AND figure out how to distribute power they don't have.

Now in any given pair of people, multiple power dynamics are in play, and figuring out who is "most powerful" is not only pointless - it's impossible. You can't just sum them. Just like with oppression generally (of which this is a tiny piece), power dynamics are intersectional.

Common power dynamics in play in a pair programming situation (low - high): * junior - senior * "wrong" background - "right" background * learning developer - teaching developer * feminine - masculine * people of color - white folks * women & other genders - men

As a white person, I think it sucks that the race dynamic that I'm on the upward side of exists, and I want to neutralize it as best I can. That means I need to actively work against it.

But say I'm pairing with a black man who is technically expert in the problem we're working on. Do these power dynamics cancel each other out? Can we go back to ignoring? Nope. As you may have figured out by now, power dynamics are something EVERYONE has to keep in mind.