Noel Rappin Writes Here

Trying to Define Undefinable Terms: The Locally Sourced Story

Previously on Locally Sourced: I’ve been writing about XP and Agile. Most recently, pair programming. And how I think about technical decisions. I started to write a different essay here, but then I realized that I was sort of depending on having written something like this. So I wrote this.

I’ve been writing all these posts about Agile and XP methods and I’ve been talking about process and about trust, but I haven’t defined them in the way I use them and I haven’t talked about how I think they are related.

Both the words are vague, but we can make them a little less vague. We can’t put a number on process and trust, but we can at least put a direction on them: we can say what it looks like to have less process, or more trust?

“Process”, in my project-specific definition, is anything that your software team does to communicate or expose the state of the project or the system. This includes all kinds of tasks, from documentation to naming code to design diagrams to pair programming to iteration planning meetings. But it doesn’t include, say, having lunch together to get to know each other better.

“Trust” — again, in the sense I use it to talk about projects — is the extent to which you accept that the process that’s communicated to you is accurate. Reading and acting on documentation is a high-trust move, reading the code after looking at the documentation is a lower-trust move.

These definitions have some implications.

• Process gets bigger non-linearly as teams get bigger, in part because the number of communication paths gets exponentially bigger, in part because there’s more conceptual distance between people.
• If you don’t have enough process, you can always augment by spending time, but if you have too much process, you can’t get the time back.
• That said, if you don’t realize you don’t have enough process and there isn’t enough communication and you don’t spend time fixing it, that’s also a problem.

Also, a process designed for a 500 person team will be a big problem for a 15 person team. The 500 person team has way more status to communicate and way more places to communicate it, so a more formal and structured process might make sense for a big team. On a 15 person team, a process of the same formality would likely just waste time. If the team is small enough to all fit in a room, you can usually just tell people things without a lot of ceremony.

“Trust” is perhaps a bit of a loaded word, but the way I’m using it there are all kinds of ways that a team might have trouble sustaining team-wide trust even if everybody on the team is personally honest. I think it’s clear how having people who are not good at their jobs or who are jerks limits trust – my point is even a team of skilled non-jerks can still have trust issues.

Different members of the team might not know enough about what other parts of the team are doing to be able to evaluate their process claims – this is especially true of large teams. I think it’s almost inevitable that a large team will develop some kind of trust issues. This also relates to the metrics post. Requiring metrics to be gathered can be a substitute for trust.

A team with large experience differences among its members might have an issue with experienced developers having difficulty communicating to less experienced ones. Or, for that matter, vice versa.

Members of the team may have different ideas about the goals of the project or what is important in the project that might cause different views of how the project is going.

You get the idea. A software project has a lot of different ideas to be communicated, and there are all kinds of reasons why a team might have trouble communicating them. Or maybe you don’t believe what I’m saying, we might have a trust issue between the two of us.

The important relationship between process and trust is that if you have less trust, you need more process. The lack of trust means you either ask people to spend more time defending what they say about the project with more formal documentation or you spend your time yourself validating what they say about the project by, say reading the code instead of the documentation. Either way, the low-trust version is more time consuming than just accepting what your team says.

You can think of trust as the amount of resistance that communication has in the project – in a high trust environment communication flows easily, in a low trust environment, communication must happen over and over again.

One thing I believe about process is that almost any process will work if the team members trust each other, and that if the team members don’t trust each other, almost any process will struggle. The extra overhead that trust problems add to communication adds weight to any process.

Which leads me to the following points that I’ve been bouncing around in all these posts:

• Many issues that present as process issues can also be thought of as trust issues, and will be difficult to fix without making improving the trust issue.
• Agile in general, and Extreme Programming in particular, assume a high-trust environment, and are not robust against trust problems. For various reasons, I think that XP assumes a higher trust environment than most teams will be able to manage, at least at the beginning of a new team.
• Many teams that have tried various XP and Agile methods have found them difficult.
• Most XP and Agile practices have evolved into versions that can more easily exist in low-trust environments.
• Trust doesn’t just mean within the engineering team, but also relates to how the rest of the company interacts with the team.
• Not thinking about diversity and inclusion issues on your team is going to make improving trust issues very challenging.

Okay, that’s a lot, now I want to start thinking about how trust plays out in these processes more specifically. Next up: estimation.