NOEL:  Hello and welcome to Episode 38 of the Tech Done Right podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. 

In this episode we're going to talk about agile processes and team dynamics, with special attention to how diverse teams can successfully implement agile practices such as pair programming and standups. My guests are Betsy Haibel and Jennifer Tu of the consulting company Cohere, and Marlena Compton who's organizing a conference on pairing and inclusiveness called PearConf. That's P-E-A-R Conf, where Betsy and Jennifer will also be running a workshop. We'll have details on that in the show notes.

Before we start the show, a few quick messages. Table XI is now offering training for developer and product teams. Topics include testing, improving legacy JavaScript, career development, and agile team process. For more information, email us at workshops@tablexi.com or check out TableXI.com/workshops which might not be available as you listen to this but should be soon. We also have a free email course and tools on improving your company's career growth and goals strategy. You can find that at StickyNote.game. 

And now, here's my conversation with Betsy, Jennifer, and Marlena.

Hi, I'm here with Jennifer Tu, Betsy Haibel and Marlena Compton. [And you] all like to introduce yourselves? Marlena, would you like to go first?

MARLENA:  Hi. I'm Marlena and I'm a software developer in San Francisco and also organizer of PearConf happening this summer in July.

NOEL:  Betsy?

BETSY:  I'm Betsy. I'm 1/3 of Cohere, a small software development and coaching consultancy. 

NOEL:  And Jennifer.

JENNIFER:  Hi. I'm Jennifer Tu. I cofounded Cohere with Betsy and I've been a developer and a manager. And I will be co-facilitating a workshop on pair programming at PearConf in San Francisco in July.

BETSY:  Along with me, I should mention.

NOEL:  Yes. Okay, so this is all related to the reason why I wanted you all here to talk to all of you. This started, at least the initial impetus for this started with Betsy put out on Twitter a couple of weeks ago now about how agile development doesn't necessarily work for diverse teams. And in particular, talking about pair programming and some of the other practices being difficult to implement on diverse teams. So Betsy, would you like to set up the problem a little bit as you see it?

BETSY:  So, this came out of a bunch of things, including a bunch of conversations with Marlena. But when you read all of the books that were written around the time of the agile manifesto, when you look at how the practices have played out, you find a lot of practices assume that power is distributed evenly within a team and that development teams are either relatively powerful or on a relatively equal standing with the rest of the organization. In a lot of cases, this simply isn't true. And the practices that rely on these benign power dynamics start to break down a little more when power gets a little bit less evenly distributed. 

NOEL:  So, how would you see that manifesting in a team where they're not understanding the power dynamics as they start trying to roll out all of these different practices?

BETSY:  Sure. Pairing is a great place to start, because pairing is one of the more common agile practices. And it's also because it's two people, a great microcosm of team dynamics. When you're pairing, it can work wonderfully well, even across a skill differential, even across a power differential, if those parties are attentive to what they do and don't know. And if both parties have an absolute baseline respect to the other person, that they know the other person is safe assuming. But even though one would hope that that was always the case, I just mentioned a lot of assumptions and caveats. For example, when I've been the only female developer on the team and I haven't necessarily been sure that my colleagues respected my skill, that's made pairing tremendously awkward sometimes, in a way that isn't always easy to resolve. 

JENNIFER:  Yeah. So, one thing that I think we can talk about a little bit is how a lot of pair programming involves this implicit agreement about not just what you're trying to code but how you are trying to work together. And so, if as a woman I or Betsy or Marlena were to enter a pair programming situation with a man, one common experience we might have is where the other person assumes that he should be teaching us. And that's a very different dynamic than trying to work together to accomplish something together. 

NOEL:  In my particular case, so much of my pairing experience has been in situations where I'm explicitly meant to be teaching somebody just because of my roles within organizations that I find that to be a real problem when I'm just pairing regularly. Betsy, it occurs to me that this is actually how you and I met. 

BETSY:  Yeah. [Laughs] I was also thinking about that. You did fine. [Laughs] There was a moment of awkward, but you did to fine.

NOEL:  Betsy and I met at Ruby DCamp about four and a half years ago in a code retreat where we wound up pairing with each other. And I don't know. I would be really curious to how you would tell the story from there, honestly. 

BETSY:  It was my first time working that particular problem, right? Early on where I was making some assumptions about how we might solve it and you interrupted and were all, "Yes, we could do that, but also I've done this before and it winds up being more interesting and faster if we do it this way." And I was a little bit taken aback, but I ran with it. It wound up being a good experience. But it was the kind of thing that could have gone in a very different direction very easily, I think.

MARLENA:  This is something I've noticed in the dynamic too, is: Is somebody teaching or are they exploring something? And I often find that if I'm pairing with someone, depending on where they are in the power differential to me, if they are assuming that they have more power, when I'm exploring or when I'm just looking at something they might assume that I don't know something or know much less than I do. Maybe this is something you've seen, Betsy, where it's like it's not actually that you have absolute no context but the other person just assumes that you don't. So, they start going into teaching mode.

BETSY:  Yeah. I think that that's a really great point. One of my friends actually, Allie McMillan, has a thing she does – she does this deliberately during interviews to see how the interviewer reacts because it's her way of doing a culture check on whether the place that she's interviewing has a decent culture around pairing. 

NOEL:  So, she deliberately goes into exploration mode and checks to see how condescending the pair programmer gets?

BETSY:  Yeah. Or makes a deliberate silly mistake that she then catches. Or just does something that is an exposed ignorance. Which is obviously a risky thing to do in an interview and I'm really impressed that she does it. But she says that she gets a lot of really great signal from the interviewer response. 

NOEL:  See, I was going to say that what I remember about when we paired together on that exercise is that I remember at the end being impressed and complimenting you at the end, and then spending the next couple of hours being really worried as to whether I'd come off as condescending in the way that I complimented you. 

JENNIFER:  So, I was thinking about what Betsy and Marlena had just said about teaching mode and pair programming. And it reminded me of when I was working with someone who – with a good friend of mine – and he always would think out loud. But he would do this in a really declarative way. So every time he did it, I thought he was being very authoritative and that he knew exactly what he was doing. And it turned out that that was not actually the case. And it took me years to realize that part of that was, "Oh, I see you as a white male with a lot of confidence in your voice. But that doesn't mean that you're trying to be authoritative." But because of the system that we're in, that's how I perceive it and that's how anyone else would also perceive it. 

MARLENA:  Yeah. That's brilliant. And that's like, I'm having that feeling of feeling so seen regarding your comment. Because, yes, 100% can confirm. I feel that way sometimes, too.

NOEL:  So, what happens when teams roll these processes out without really understanding their team dynamics? What are some of the things that a team can look for to see that they have some work to do? You're starting to do more pairing, you're starting to do more TDD, you're starting to do story time and things like that. But you don't have a team with equal privilege or you have a very diverse set of backgrounds and expectations and communication styles. What are some of the signs that you need to do some work trying to put this together better?

JENNIFER:  One of the things that Betsy and I are doing is we're making this workshop called ‘Pairing with Privilege' which we will be giving at PearConf in San Francisco in July. And as part of that, one of the things we've been exploring is: How do we build a library of smells? In programming, we talk about smells. Like, "Oh, this doesn't smell quite right. Something's a little bit wrong with your code." And you can build these catalogues of code smells and then corresponding recipes for how to fix it. And so, we've been building this catalogue of pairing smells and what you can do to fix it. 

BETSY:  One of the great ones is people going quiet. And this applies not only to pairing but also more broadly. If you're looking at for example retros as an agile practice or estimation meetings, or any of the many, many agile practices that involve a lot of real-time synchronous communication, look at who talks and who doesn't. 

MARLENE:  Who's typing and who's not typing.

BETSY:  Yeah. 

MARLENA:  The keyboard is actually I would say a very good indicator. Who is typing?

NOEL:  In pairing? So, if one person's doing all the typing, you may be doing something interesting and useful but you're not pair programming. 

MARLENA:  Absolutely. I know that a lot of people think about it in terms of like, "Well, if somebody knows more maybe they're just deep in the code and they're just focusing and their pair is focusing with them." But what happens is the person who's not typing, it's going to be really boring and hard to pay attention and hard to stay with your pair. And you're going to get lost. And so, having sort of equalizing access to the keyboard, that's just so core to having a better pairing experience. And one thing I wanted to mention about having smells when it comes to pairing is, I would not even wait I think to see smells. If you're rolling out pairing, I think it's taking a step of fundamentally recognizing that you're doing this which means your team has to start looking at how people are working with each other and how people are talking with each other. And that you're going to have to focus on equalizing things as just part of doing it at all.

JENNIFER:  Can I push back on that a little bit, Marlena? I feel like you should not be waiting for smells. At the same time, you should also be actively looking for smells. Because you might have picked one technique that would make it easier to do turn-taking. Like maybe you're doing ping-pong. But just because you've picked this technique and it usually works doesn't mean it's always going to work or that it will work the third hour compared to the first hour. 

NOEL:  Ping-pong pairing is a pairing technique where one person writes the test and the other person writes the code. So, it enforces going back and forth and having both people type. 

BETSY:  Yeah. And the thing I love about that Jennifer, is that also gets at the idea that no single technique is a silver bullet. Just because ping-ponging is great for keeping people from hogging the keyboard, people can still do strange and passive-aggressive and sometimes even aggressive things in the context of ping-ponging or in the context of communication around ping-ponging. If there isn't that baseline teamwork and ability to work effectively together that you're establishing really consistently and constantly, then stuff is going to creep in around the edges of the techniques you're using.

NOEL:  A certain amount of passive-aggressive behavior is sort of part of ping-pong pairing. 

[Laughter]

MARLENA:  Ping-pong pairing is hard.

NOEL:  Yeah. And because… 

JENNIFER:  It is not that passive-aggressive.

[Laughter]

MARLENA:  It's hard.

NOEL:  So, okay. So, what's passive-aggressive about it is, at least in the way that I've done it or seen it done, what you do is you write the test and then the person doing the implementation writes the bare minimum to make the test pass in order to force the tester to write a better test. This assumes that both people: A, know what they're doing and B, are really comfortable messing with each other a little bit. 

MARLENA:  And with test-driving. 

NOEL:  Yeah. Right. There's a lot of implicit assumptions built into that. But one of the things about it is that one of the moments in ping-ponging that you're really happy with is when you write deliberately dumb code to make the test pass and force the test person to write a better test. But that obviously becomes tricky if you have one person who is in a more powerful position than the other person. It's a hard technique to do right.

JENNIFER:  Now I'm really curious. Do any of you use ping-ponging except at code retreats?

NOEL:  Okay. I have a complicated relationship with pair programming in general. And I do not normally ping-pong.

BETSY:  I've ping-ponged outside of the context of code retreats. I don't necessarily troll-pair when I ping-pong. I think that troll-pairing is really fun when you have a rapport. But it needs to be something that both parties are consenting to. 

JENNIFER:  It's also fun for you Betsy, because you always win.

BETSY:  That's not quite true. [Laughter]

JENNIFER:  Fine, you always win when we're troll-pairing. 

BETSY:  There are people who can consistently beat me at troll-pairing. 

MARLENA:  Can we define this troll-pairing?

BETSY:  Troll-pairing is when – is a subset of ping-pong pairing where you are trying aggressively and deliberately to mess with your partner in the service of the code. And if you can create a safe space, then it's actually pretty fun. If you can't, it's horrific. 

MARLENA:  That definitely sounds like something you do with a close friend.

BETSY:  Yeah.

MARLENA:  I've done ping-pong outside of code retreat. But one thing that I've come to recognize about it is I think that it's actually one of the more complicated ways to set up pairing, just because of how much it assumes and those implicit assumptions that we talked about a little bit. So, I have started looking for ways to take turns that are not necessarily ping-pong. And I've found that to be – people talk about ping-pong I think because it has a recognizable term and it's connected to a game so it's fun to think about. But I actually think it's harder to get that going than to take turns in another way sometimes. 

JENNIFER:  Yeah. That's true. Now you're making me think about the last time I was doing ping-pong with someone that wasn't troll-pairing. And in that particular case, I was pairing with a good friend. And we ended up having this intense discussion about whether or not our objects should be mutable. And I was coming from a ‘mutate everything' standpoint. And they were coming from a ‘no, an object is an object and you don't ever touch it again' kind of a standpoint. And because of our relationship, we were able to use the constraints of ping-pong to have that discussion while taking turns. But it can be really easy for someone to not do that turn-taking and seize control because it's their turn to do the ping-pong. 

NOEL:  Yeah. It becomes a delicate balance of where there's a genuine difference of opinion playing that out in real-time as opposed to in a somewhat reserved – like a code review. It's tricky, I think. So, there's a couple of practical things that we've been doing here, that we've started doing. And I'm not entirely sure how they're going to play out. But one thing that we did that was very useful on my team was we invested in a couple of bluetooth keyboards so that anybody can go over to somebody else's station and plug the keyboard in and have the keyboard/mouse combination on somebody else's computer. So, you're not fighting over people's keyboards on their laptop, which I think some people find off-putting. So, that's been valuable. We're trying a thing here where we're asking people to be very explicit about communication styles and write down a couple of things – actually write down on paper – a couple of things that they like to do when they pair and that they don't like to do when they pair. So that you can learn a little bit about the person before you go. We're kind of seeing how that works. It's something we just started. One of our apprentices took the lead on trying to get everybody involved in this. I think it's interesting and we'll see how that goes. 

MARLENA:  Pair check-in, checking in with your pair before you actually start working I think is extremely valuable.

NOEL:  Yeah. So, what are some other techniques that teams can do to try and improve the quality of their specifically pair programming at first but in general their agile adoption, agile process?

BETSY:  Honestly I would say that the biggest thing you can do doesn't lie in the context of pairing but lies outside of the context of pairing. You need to invest a lot in building team rapport with each other. You need to foster at least some level of meaningful friendship between employees so that when they do disagree, or when there are misunderstandings, they're coming from a fundamental context of trust. Pairing can be a great way to build trust when it goes well. But there's that ‘when it goes well' caveat. 

JENNIFER:  I would say you also want to make sure you're getting everyone involved, whether that's the two people in a pair or everyone on the team, to be invested in making sure that everyone's voice is able to have the space that it deserves. And there's a couple of tools that you can use for that. The Ada Initiative put out this guideline for a couple of roles that people can take whenever there's a meeting. You can have someone who's facilitating. So, their job is to make sure that conversations flow smoothly. You can also have someone who's more of a gatekeeper, so making sure that everyone is able to have their voice heard. And it's less important who does these roles and more important that everyone sees why these roles need to exist and work together to accomplish all of the tasks that those roles accomplish.

MARLENA:  And shameless plug, if you come to PearConf you will see this type of facilitation style in action. Because this is how we're going to be doing our unconference sessions. 

NOEL:  So, what does that look like in practice? What is somebody actually doing in the facilitator role?

JENNIFER:  Can we frame this in terms of a retrospective since we're talking agile?

NOEL:  Yeah.

BETSY:  Yeah.

NOEL:  Yeah, take it away. What does the facilitator do in your ideal agile retrospective?

MARLENA:  The facilitator in the retrospective is the person whose kind of setting up the structure. In the retrospective, usually you have a gathering phase where you're gathering feedback from all your teammates. So, that person's going to be in charge of that type of thing. And also, transitioning between the different phases of the retro. So, they're kind of overseeing the structure of the discussion as much as there is structure, a little bit. Then there's also a timekeeper. So, somebody who is just looking at the clock. Because if you're trying to facilitate discussion, making sure items are discussed and prioritized and grouped – there's a lot happening in a retro – you can't also be looking at the time. So, have a timekeeper. And then also, there's gatekeeper. And the gatekeeper I have seen less of out in the world. But I wish more meetings had them. This is the person who if somebody is always taking a turn or if they are taking a turn and taking up all of the time, it is the gatekeeper's job to let that person know and bring in some other voices.

JENNIFER:  I feel like when I've seen gatekeeping in the real world, it's always been the facilitator. So, whoever is running the meeting is also the one who's gatekeeping. But it's a really hard skill to be able to do this. And most people who are facilitating can't do it.

BETSY:  Yeah.

MARLENA:  Yeah. Like I actually think retros can be one of the more painful meetings for if you're an underrepresented person just because it's – unless you have a facilitator who understands making space for you, chances are you're going to have to figure out: When can I actually speak? And this is tough. It can be really tough. 

BETSY:  Yeah. In a retro as an underrepresented person, you may often have a radically different opinion of something that's going on, on the team, than the rest of everyone else. And there is always the decision running through your head. Do I speak up about this? Do I not speak up about this? Will I lose political capital? Is it worth spending that political capital on this? Et cetera, et cetera. Even in retro situations where there is some level of anonymization going on, there's never really anonymization if you're the only person from a given background in the room. That's just not how it works. Unless someone is actively trying to make sure that all perspectives in the room, it's pretty easy to deliberately suppress your perspective or paint it as other than it is. And retro facilitation is hard in the absence of someone taking care of that role. A lot of things are going to get lost. 

NOEL:  One thing that I do and I [may assume] your opinion about this. I don't normally make a big deal out of this. But after we finish gathering stuff in a retrospective and we start trying to decide which topics to discuss, rather than do a dot vote, what I usually do sometimes is to go around the room and ask individual people which gathered item they want to speak about first. And I usually start without making a big deal out of it or saying that that's what I'm doing. I start with the most junior person on the team to at least ensure that the most junior people on the team have the opportunity to have their issues discussed. It's a starting point. And I think it requires a little bit of trust across the team. But it's something that I try to do when I facilitate a retro.

JENNIFER:  That's really neat. I'm going to steal that idea. 

MARLENA:  It is a good one. I've also sometimes had people go around the room just to make sure, see if each person had something they wanted to add. And that helps at least give each person an explicit chance to say something if they need to.

NOEL:  Yeah. I like to do that. I particularly like to do that if there are a couple of people who are remote to make sure that they get a chance to chime in. I also think that dot voting tends to eat up five to ten minutes of time. And if you just go around the room and ask people what their most important ticket is, you will talk about the same tickets as you would have dot voting. You just have ten more minutes to talk about it. 

JENNIFER:  I do feel like dot voting does have a purpose, which is any time you have a group of people together that group is also an entity. You have all of the individuals that comprise the group and you also have the individual that is the group. And when you dot vote, you're uncovering what the group as a whole is looking for.

NOEL:  I probably should define the term here. Dot voting traditionally is like every individual item in the retro is on a sticky note or a card or something and people walk up to the card wall classically and put a dot next to the item they want to talk about. Then in theory, the one with the most dots is the one you start with. 

JENNIFER:  You get this heat map of all of the – of everything that everyone is interested in. And you see what, as a group, the group is most interested in.

NOEL:  Right. And I guess dot voting does have the, "I'm not alone. Somebody else wants to talk about this," which I think could also be a valuable signal.

BETSY:  It is a valuable signal. It is also subject to weird social clustering effect sometimes. If you're the person whose gone second or fourth then you're going to be paying attention to what people have already voted for and you're not necessarily going to want to throw your votes away on something that isn't going to make it.

NOEL:  Yeah. So, no technique is perfect and you should try different ones and see what works with your group.

BETSY:  Yup!

NOEL:  "It depends," is always the answer. 

MARLENA:  Betsy, you just made dot voting sound like voting in the primary. 

BETSY:  [Laughs] 

JENNIFER:  You can't take social factors out of anything.

NOEL:  I've certainly been in situations where I'd be like, "Oh, that ticket doesn't need me to vote for it because it already has enough votes for us to bring it under discussion."

JENNIFER:  This gets back to the thing that we keep on implicitly pointing out, which is we can talk about individual techniques for making agile healthier either generally or specifically on diverse teams all we want. But you can't rely on any given technique to save you, because the actual thing that will help is looking at the power dynamics on your team. There are no substitutes for that. 

MARLENA:  And trust is the foundation. It's never different. 

NOEL:  I would say that to some extent, this has been a known issue about agile and XP since the jump. It's been a critique of agile since the very beginning that one bad actor can blow up a team. And I feel like agile processes in general depend on a certain amount of reciprocal trust. And if you're in a situation where a bad actor is not giving reciprocal trust but is demanding it, then that's a problem. And if you're in a situation where systemically, you have power dynamics on your team that make that kind of trust hard or impossible, you also have a problem. I don't see the current discussion as being tremendously divorced from critiques of agile that have been made for 15 years.

BETSY:  I don't need it to be novel. [Laughs]

NOEL:  I think it's a useful discussion to have. I'm not saying, "Oh, that silly old thing again?"

BETSY:  No. I know what you're saying. And I think that there is a point to that, right? Like… 

MARLENA:  Well, that's part of the assumption, that I think that if you're assuming everyone on your team is homogenous and you all are coming from some common background, then that makes it much easier. And that's where this was when it all started.

BETSY:  And I think that part of the issue is that we've been talking in generalities through a lot of this recording because if I were talking about the specific things I've experienced, first off some of them are things that I'm not sure I would be comfortable talking about without heavy degrees of vaguery in a public forum. But second off, I would be talking from my position as a queer woman. I don't want to paint this issue with something that's only about women versus men dynamics or only about queer versus straight dynamics. That leaves out a lot. But just because I don't want to leave out the fact that racial dynamics, disability dynamics, etc, have huge impacts on agile – and oh boy, do they – I have been in situations where I have dealt with temporary disability. And actually standups are not good if one person on your team is really seriously sick. We don't think about this, but standups can be seriously not good sometimes. Sorry, that was a tangent. 

MARLENA:  It's a great tangent. Keep going. [Laughs] 

BETSY:  Yeah, no. I was in a position where standing up for 15 minutes or 20 minutes was actually very, very physically difficult for me. And I didn't want to have to admit that to my team. And so, I stood up through the entire standup. And it was terrible and I was useless for the next hour. And a lot of what we've been doing is talking in generalities. But this doesn't come out in generalities. It comes out in specifics. It comes out in the fact that if someone is trans and their first introduction to their team's new scrum master is that person flinching slightly when they meet someone who is visibly trans, then you can't come back from that without enough of a safe space for that trans employee to talk to someone and enough of a safe space for the person they talk to, to do something about it. And that is not a theoretical story incidentally. That is something that I needed to deal with and couldn't deal with at a past job on someone else's behalf. 

When we get into these specifics, we start getting into why this is different than the generic critiques of agile that have already existed. But also, it takes place in the context of the fact that those critiques are still real. It takes place in the context of the fact that this has always been a problem. It's just, we're noticing it more now because the industry is not entirely made up of young, white men anymore. 

JENNIFER:  Yeah. And it's not just about having safe spaces in which you can bring up accommodations or that you can exist as a trans person or exist as someone who's different. It's also about having the support structure that encourages that, and encourages the team to embrace you and to support you. If someone's going through a difficult time and has an invisible injury or an invisible condition that makes it hard for them to stand, even though their team might support them in that, everyone is so used to standing up at standup that every day becomes the struggle of, "Do I remind them that this is hard?" And that itself is something that you can't solve just with safe spaces.

MARLENA:  I think in design there's this concept of – this is maybe from the 60's – the standard height of a countertop for a standard average human.

JENNIFER:  Male human. 

MARLENA:  Yeah. 

NOEL:  All kinds of things have been designed against a mythical average. Car seats maybe most dangerously. 

MARLENA:  I think agile is exactly the same as this. And this is kind of what we're going over now. It's like, okay, so when this was designed – and it was designed by all white men at a ski resort and there's an article now from The Atlantic by somebody describing this resort – but yeah, so this is where we got this. And you can see them all in a photo.

NOEL:  The practices predate that ski resort. The people in the ski resort were all people who had used different forms of practices. The practices were informed by a lot of different people, most of whom – the overwhelming majority of whom – were white men. But the agile – I don't know. This is probably a tangent that I shouldn't bring up. But the manifesto is not the practices and the practices are more than the manifesto. And I think we all bring stuff. Everybody brings stuff to their practices and their team.

JENNIFER:  Marlena, I feel like what you're saying is that agile is the process manifestation of the same design principles behind how we work, which includes things like: How is our office set up? And agile is the invisible non-physical artifact of that design thinking. 

BETSY:  And what's interesting about that is that Noel has this immediate recall of the fact that the manifesto came out of the practices and is not the sum of the movement because a lot of agile has been about this processes that are passed down through an oral tradition, through practicing them, and that contagion. And that inherently means that only people who have access to the spaces where "real agile" is being practiced have access to the context of how these practices are meant or were meant to be used, to the context in which they were developed and the context in which they are known to be effective. That means that if you're someone who's traditionally not had a lot of access to those spaces, how are you supposed to learn the right way? How are you supposed to learn anything but the thing that gets filtered out through 3,000 layers of some PM's happy horse and that VP of Engineering reading a book once? You can't.

NOEL:  I mean, I was basically the guy who read a book once and tried to make my team agile based on it before the manifesto. 

BETSY:  No, I know. But there is like – if you look at the books, right? There's a lot of emphasis on the importance of that oral tradition and that one-to-one stuff. And one of the things that struck me originally and made me go, "This is something that is stealthily anti-feminist," is that if you're a woman in this industry, that one-to-one mentorship relationship with a dude is never entirely uncomplicated or accessible in the way that it can be between two dudes with roughly the same background, even if they've got different experience levels. 

MARLENA:  Betsy, that was awesome. I think that one thing I've kind of noticed at this point is – and sure, there were practices before there was a trip at a ski resort – but we now have an institution. And so, there's like this conundrum of, "Well, if you're doing agile ‘right', you're going to be making changes. Your retro is going to look different in a few months. You might change some things up. Do some things. Not do other things." This change is at the heart of some of this. However, we now have an institution. There's the Agile Conference. And I know this gets into the big A, small A thing. But this, I think this is something people in teams have to think through. And it's like, there's a certification. There are books. It is an institution. It is harder if you're the underrepresent person on your team. And the books are saying, "You're supposed to stand up," but it's very difficult for you. It is difficult to challenge that. But I think that a lot of us are at the point now where we're like, "Well, but yeah. We want to include more people. We want it to be okay for people to sit down when they need to sit down." And so, I think that what's going on with a lot of this – this is certainly the type of thing that's behind PearConf.

NOEL:  One thing that speaks to that point to me is that even from the very beginning, the XP mailing list and things like that were very defensive about people coming back and saying, "I tried XP and it didn't work." And there was a very strong sense of, "If it didn't work, you must have done it wrong." Even from the very, very beginning before – and I think it's only gotten worse as there's been, as you say, this huge institution that is built up around it. Yeah, I think that goes to your point. 

JENNIFER:  It's really hard to do something and learn that you might not have been doing it entirely right. And whenever you learn something new like, "Oh, standups are really physically hard for my teammate," or, "Oh, this new person on my team feels like they're not able to be fully present when we're pair programming," whenever you learn something like that, there's this awful realization that maybe you weren't doing things right. And if your identity is tied up around, "I'm someone who does agile and I do it right," then that's a really hard thing to hear and a really hard thing to overcome. And that's part of what makes this entire conversation around agile and the difficulties around agile while we're thinking about all of the privileges that we bring in from our stances in society, that's what part of what makes this conversation so hard. 

MARLENA:  It is. And it's this idea of having to be perfect. One thing that I try to deal with it is back away from this idea of perfection and dismantle – like in XP there is the book with the 13 – am I right, that's 13? I think it's 13. 13 practices.

NOEL:  I honestly don't remember. 

MARLENA:  That you're supposed to be doing – there is the contingent that's like, "You have to be doing all 13 of these or it's not XP and you're wrong." [Chuckles] But what I want to do is kind of take this apart. It used to be people were like, "Well, you have to do all of this together." And I just, I don't think that's true. This is not what I've seen. I think you can do some of the stuff. This is what I hope we're reaching for, is backing off of this idea that everything has to be perfect for us to ship software. Because I think at this point, we all know that shipping software versus perfection, these are two different things.

NOEL:  Yeah. There's always been this weird tension in agile where there's always been the sense that agile has to adapt to your local team, that the whole point of it is change. And yet, at the same time, there's always been this really strong contingent to say, "You have to do it the way that it says on the box or else it's not going to work." And I've never really felt that the out-of-the-box thing works for anybody. Some of the original XP practices were probably never done by any team outside the original team. I don't know. How do you guys feel about that tension?

BETSY:  I think there's a real fear of delusion, right? I think that there's a real fear that you're going to slide into water-fragile on a team that's only starting to introduce agile practices. That if you don't buy into the system whole hog because of pressure from external stakeholders – and this gets back to the idea that agile has historically relied not only on relatively homogenous teams but on that team having a pretty decent level of power and autonomy relative to the rest of an organization – because yeah, how else are you going to push pair programming through in an environment that's only ever soloed? But that fear maybe isn't as valid anymore. I'm not saying that all software organizations are healthy or that the broader world understands what good software teams do. But I think that in a very real sense, agile has won. And I think that recognizing that agile has won means that it's safer to do a higher degree of adaptation than it was back when people were worried that the spirit of the thing would get lost in that adaptation.

MARLENE:  I think that change has won, because change is inevitable. And that's the thing that I think agile got so right, was recognizing the need to be able to work with change and flexibility.

NOEL:  I completely agree with that. 

JENNIFER:  Yeah. Agile is a process. And just because a process is something you're doing the same day in, day out, doesn't mean that it's not also at the same time this living dynamic entity that is going to change and adapt. So, the thing that you're doing every day when you're a team of three is going to change and adapt as you grow to a team of 13. And you can't expect the identical process to serve you at a team size of three as it does at 13. And you do want consistency but at the same time you want to be able to adapt and go to where your team is. You want to adapt as your team grows. You want to adapt as your team members suddenly find themselves unable to stand in standup. 

NOEL:  Alright. If people want to talk about this more with you online, you can talk to me @NoelRap on Twitter. Where can people reach you?

BETSY:  I can be found at @betsythemuffin, no spaces, on the Twitters.

NOEL:  Jennifer?

JENNIFER:  @jtu on Twitter or email jtu@wecohere.com. 

NOEL:  And Marlena?

MARLENA:  I am @MarlenaC on the Twitters and also the PearConf twitter is just @PearConf.

NOEL:  P-E-A-R Conf. 

MARLENA:  P-E-A-R the fruit. PearConf is, it's going to be a two-day workshop/unconference. And while it's kind of centered on XP-ish practices like pair programming, this is a radically inclusive conference. And so, it's designed to decenter people with more privilege and allow for more discussion. So, we are kind of looking at: How do these practices work in the real world where we're all building products and trying to get the software out the door? And it's July 13th and 14th.

NOEL:  Great. Thank you for being on the show. I really enjoyed the conversation. And I hope that people follow up with you and the conversation continues. 

Hey, after we finished the main recording for this, we were talking in the post-production and I went back and talked to Marlena about something that I had done in the conversation that bothered me a little bit that I wanted to clear with here. And so, we had a little bit of a conversation of it that I thought was interesting enough to share with you. So, we're going to add it here at the end.

NOEL:  Marlena, I'm sorry. I hope you didn't think I was stomping on you. I didn't mean to. I think you all called me out suitably. 

[Laughter]

JENNIFER:  I have no idea what he's talking about. 

NOEL:  When I was talking about the practices not being the manifesto.

JENNIFER:  Oh. Oh, that. 

NOEL:  I realized that that may have come on a little strong there.

MARLENA:  Thanks for saying that. I realize that's one of those things that is important to people. 

NOEL:  I just, I feel like there's a context that sometimes gets lots in the conversation. It's not even that I disagree with the idea that it was built by a certain group of people who all kind of agreed in a certain way. 

BETSY:  Going in a slightly different direction, it is weird and kind of wrong, the fact that there were women who contributed meaningfully to the set of practices that turned into the manifesto has gotten erased, right? And that that got erased because they didn't really want to go to an event at a ski resort they knew was going to be mostly men. 

MARLENA:  Yeah. I think that made me angry when I read that article. It's like, you knew that these other people had made important contributions and just ignored it.

BETSY:  And attribution is a feminist act. And I don't think it's wrong to want to complicate the usual attribution of the agile manifesto. 

NOEL:  I agree with that. 

MARLENA:  I specifically wanted to bring up the ski resort because that's part of what we're doing is I want people to rethink this. And that's like, that article was a very clear illustration of why it's worth going back and thinking about, "Okay, what are we doing? Where is this coming from? How do we involve other people?" So, that's why I mentioned it in the first place. 

NOEL:  Yeah. Thank you. As is often the case, you are right.

MARLENA:  It's cool. And I'm just so happy to be invited to this podcast. So, thank you for having us.

Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm @NoelRap on Twitter and Table XI is @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts, including Spotify. You can send us feedback or ideas on Twitter @Tech_Done_Right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications, and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.