Is Trust a Value?

During our previously mentioned Continous Learning session at work, Brett, our manager, asked if Trust was a value. My response was that Trust is something that is encouraged by the five other values, but I didn't think that it was a value, though I wasn't necessarily convinced one way or the other.

I was reflecting on this a couple days later on my way to work. The long and short of it was that I had reasoned my self to the following: Trust isn't one of the values, but Trust is something that we value... Huh? Ok, so Trust is a value. And it is something that I think we will be stating as one of our values.

Values

As a team (including our Engineer and Product Manager) we are doing some Continous Learning on Extreme Programming Explained, 2nd Edition. I've read the book a couple of times now and am in the process of re-read it again for the group discussions. There's one sentence that really stood out for me, which was:

The difference between what I think is valuable and what is really valuable creates waste.

That sentence is one that I had read twice in the past but the power of the statement didn't really hit home until the third time I read it.

I don't like waste. What is the point of doing something if the end result is that there is no end result. Nothing that was done would have any value. That's what waste means to me. If the members of the team I work on all have differing values, then we are inheritly going to be wasteful to some degree. Therefore we, as a team that is part of a business, need to identify what values are important for us. It's subtle yet important to me that that statement makes it clear that teams need to find what they value and actively encourage one other to live up to those values to be more effective as a team.

The value of communication

We've rearranged our development environment after we finished wrapping up development on Track Changes to help move the team more towards XP. Previously, all the developers were in an area with a desk running around the perimeter of the area. Each developer was spaced out equally around the rim of the room and each developer sat facing the wall. This situation is not unlike some cubicle set ups I've work in at other companies (though at the other companies the developers were a bit closer together, but not that much more).

From the old location we moved to a smaller space that has a large enough table that we can comfortably fit developers down either side of the table plus a small desk area running along one of the walls of the area. Two of sit along the wall, while the rest of the team is on the table. The main reason for moving to the new area was to give us comfortable room for some pairing stations. But, the biggest benefit in the moves is that our communication within the team has dramatically increased.

With all the developers facing the wall, we tended not to interrupt one another unless we definitely needed some assistance. But now the development area, at times, is just one big running comversation about the numerous things we are trying to accomplish during the day.

Sitting together is one thing, but it's important that you sit together in a way that fosters the sort of conversations we are experiencing. Don't sit facing in a direction that you can't see anyone. Make sure that you developers can easily see each other and make eye contact. It just makes the process that much more humane.