Noel Rappin Writes Here

Or: Trust Goes Every Which Way, And Makes Agile Work

Previously on Locally Sourced: I attempted to justify all this agile stuff. Before that, more agile stuff. Also, I have a book out, and good marketing practices would suggest I mention that from time to time.

This time around, I’m worried that all these words won’t help make the central point: Everybody on a software team should feel included and safe in their work because it’s the right thing to do. An agile team has a particular responsibility to ensure that everybody on the team is included. Not only is it important in its own right to treat team members well and make them feel included, it also, and very much secondarily, helps the team work better. I will now spend about 800 words making the same point, hopefully more entertainingly.

Entropy Essays, Explained

The idea behind the Entropy Essays is that the XP and Agile practices as I see and hear them implemented don’t always seem to have the intended effect of creating functional development teams. In particular, the XP and Agile practices are often not resilient in cases where the entire team is not on board 100%, and many times a halfway done version of the practices is less effective than not doing them at all.

So far, we’ve talked about technical practices. I want to mention a baseline assumption of the original XP/Agile practices that I think has persisted as Agile has evolved over the last 20 years. It’s implicit, but it’s definitely there, and once you notice it, it’s hard to unsee it.

Agile teams depend on reciprocal trust.

What is Reciprocal Trust?

The Agile practices implicitly assume that everybody on the team will feel safe and empowered to give their opinions on how the team works, and that everybody on the team trusts the good intentions of the rest of the team. The practices also assume the team will be trusted by the rest of the organization to run itself. Without these assumptions being true, an Agile team is much less effective.

You can see the need for expected trust in the practice of pair programming. Pair programming not only requires that the team feels empowered as a whole, it also requires that for every possible pair of developers both developers feel safe and comfortable in a one-on-one situation.

You can see this need for trust in the planning game. The planning game assumes that every member of the team will feel equally able to give opinions about estimates, and that the team’s estimates will be respected by the rest of the organization.

In cases where this trust does not exist, many of the Agile practices do not work.

Breaking Trust

It’s long been known that one bad actor can derail an Agile team, but it’s also true that one person can derail an agile team even if they are only malicious toward one other member. Do you have a senior developer who is condescending and dismissive of a junior developers, or of developers with a different background? You have a team that will derail, and more importantly, a developer being treated badly.

It’s even true that the team can be derailed without malice. Lack of understanding or empathy on the part of team members can lead to other members of that team being treated poorly, and therefore being unable to trust the rest of the team with their safety. Do you know what every member of the team needs to feel safely able to give technical opinions? If you don’t, you won’t have an effective agile team. The members of your team will not grow.

Everything is Process, Politics, & Management

You will sometimes see developers, even developers who signed the Agile Manifesto and should know better, scoff at the idea that there is any social or inclusivity dimension to the XP practices. “It’s just technology”, you might hear them sneer, “TDD doesn’t care about social factors.”

And yet. Even if I was willing to allow that TDD was just a technical solution without a social dimension – I am not sure that I am, but even so – introducing a practice like TDD to a team and having TDD become part of a team’s ongoing process inevitably has a social dimension. You have power relationships in who decides whether the team is going to do TDD and what qualifies as TDD. You have people who may be more or less comfortable with the process who are either going to be supported as they gain knowledge, left to fend for themself, or denigrated for their lack of knowledge.

It’s something that I’ll probably say a lot here, but you always have management, you always have process, and you always have politics. It’s just a question of whether you are aware of them and deal with the issues explicitly or whether you ignore them and wind up with a set of unwritten implicit practices. Implicit practices are inherently difficult for new team members to learn, and are inherently anti-inclusive.

Because Agile is supposed to be adjusted to your own team’s needs, Agile teams often have a lot of implicit practices.

What Can I Do?

If you are on or are leading a team that uses Agile practices, what can you do to make sure the team is inclusive? I don’t have all the answers here, but I think the answers start with understanding that there may be issues you don’t see and by listening to your team. If there is somebody on your team who is quiet, and never participates in retrospectives, that might indicate a person who does not feel empowered to express opinions. Exactly what you might do in that case depends on the person, but encouraging them to express opinions privately or making a point to encourage and support them when they do participate are both things worth trying. (I would advise against putting them on the spot and surprising them with a demand to participate in a public meeting.)

If you want to hear me learn more about these issues in real time, please do check out this episode of Tech Done Right, where Marlena Compton, Betsy Haibel, Jennifer Tu and I discuss diverse agile teams. It’s probably my favorite of all the Tech Done Right episodes, in part because it’s something where I came in thinking I knew enough about the issue to care about it, and yet was successfully called out by all three guests and shown aspects of Agile and inclusion that I hadn’t considered.

I’d really love to hear from you as to whether I got this one right. Please do comment and let me know.