Is the best way to interact with your team in person, with your teammates right next to you? Not necessarily. By working online with remote programmers and testers, people tend to approach problems from some unique perspectives. Read on to learn how imagining an ocean between you and your teammates can actually improve your communication and process.
Is the best way to interact with your team in person, with your teammates right next to you? It seems reasonable on the surface. Had you talked with me a year and a half ago, I might have agreed. Now? While I do feel in-person, immediate communication is valuable, I have switched my thinking completely about the idea that proximity automatically equals more effective.
I work for Socialtext. Our company makes a product that is also called Socialtext. It's a collaboration platform built around a wiki engine where users can edit documents, communicate with each other, and perform many business functions together.
My company is a lot of things, but the most important attribute from the very beginning has been distributed. Socialtext formed around the idea that there was no central office. Our engineers are all over the map. We meet up each year for true face-to-face interaction, but the key to Socialtext's efforts has been the idea that we can be anywhere, and we expect anyone who works here to be effective anywhere.
That's great, but what does this have to do with better testing? Well, our testers are likewise distributed. By working online with remote programmers and testers, we approach problems from some unique perspectives. Tools seen as interesting curiosities in some organizations are mission-critical for ours. I have come to see that this distributed workflow even has advantages over working with those who are right next to you. I'll even go so far as to say that testers who are in the same office might benefit from our approach. Curious? Then please, read on.
Take "Dog-Fooding" to the Maximum
Socialtext, more than any other company that I have worked for, does everything in its power to use its own product. The operating and guiding rule that we all follow is "If there is a business function that we need to perform, we will do it with Socialtext, we will develop a way to do it inside of the Socialtext platform, or we won't do it at all."
With one notable exception, we are true to our word on that front. All of our intra- and interdepartmental documentation, user stories, bug entries, and kanban board live and operate inside the Socialtext platform. A large percentage of our intra- and interoffice communication happens through it. We write and store our automated tests within our application. "Socialtext calls on Socialtext to test Socialtext” is a correct sentence—yeah, it's that meta.
IRC and Screen, the Best Learning Tools
Having said all that, we do have notable exceptions. Because it is well established, we have used Internet Relay Chat (IRC) since the company's inception. In essence, the various channels on our IRC server are the most important places we can be at any given time. Everyone has their audible alerts on for IRC during standard hours. This means if you get a ping from anyone in our IRC groups, you are expected to respond quickly. (Within a minute is the assumption, and usually the actual response time is far less.) The main groups are archived each day. For 1:1 typed conversations, every individual in a shared IRC channel is a double-click away. Those conversations are private and are not logged. To work heads-down with one person, moving to a private chat keeps the main channels from becoming cluttered. To work with more people, shared desktop and audio channels of several flavors are available. I cannot count how many times I've been trying to chase down an issue or get some feedback on a new story and found all of my answers, and then some, in the chat transcripts. This is one of the very few business functions that does not take place, by design, within the Socialtext platform. If all else fails, we'll still have IRC.
We also make heavy use of GNU Screen for collaboration and pairing purposes. One of the most common refrains heard (or typed) is "What's your screen?" This allows any of us to jump on and see what another person is seeing, programmer or tester, two seats away or across an ocean.
Going back and reviewing screen and IRC logs each day is one of the best examples I know to watch learning as it is happening. Here is where I will say the distributed model we use is most powerful. When we are next to each other, a lot of what we discuss is implied or may be accomplished because someone on one side knows what needs to be done and the other participant is just along for the ride.
With IRC and GNU Screen, both participants have to communicate their understanding of what is going on. Both need to collaborate on an equal footing. I enjoy watching the gears turn and the realizations happen as we talk through problems and work through stories. We can verify if what we know is right or if there are misunderstandings. We're set up to use phones or talk face to face, but there is something magical about reading through the logs of a chat session. Real learning and understanding is visible, and it's documented for all to see.
Skills Develop Faster as We Teach Each Other
The best and most educational experiences I have had at Socialtext have been when a group of us get on IRC to work through stories in real time. Sometimes that's the middle of the day with a mostly local group, and sometimes that's late at night (for me) with our programmers over in Taiwan or India, where it's early morning.
Communicating like this means I have to be more deliberate in my conversations. It pushes me to be more concise and more focused and to work to get to the heart of problems quickly. Because IRC chats are logged, we can go back later and mine what we talked about, as well as witness real-time learning as it is happening, keeping the context of the conversations intact. As I am explaining issues, the programmers are considering what I am saying and looking at the code at the same time. Often, before I even finish explaining all of the steps, they have determined a course of action to fix a problem. It's real-time pairing and learning, even though we are an ocean apart.
Garden the Knowledge Gleaned from These Sessions
We are all encouraged to go through and update our How-To section in our internal wiki. These guides can be as simple as a few commands to fix a development environment that's gotten out of sync or as complex as full-scale deployment scripts and processes that we all use. We actively encourage everyone to explore chat sessions, personal notes, and methods we all use in our everyday work.
I have a four-step process I use. Questions start in IRC and become tracked conversations. If something seems like it will be a consistent process I will use, it gets placed into my "sticky notes" application. The sticky note phase is time-bound and use-bound. I keep sticky notes for sixty days. If a note isn't used in that time, I discard it. If it does, I change the color of the text each time I use it. Text starts as black, then I change it to green, then to blue, and finally to red. Red is my indication that I have something being used a lot that could be valuable to others on the team. My third phase has me putting these notes into my own personal wiki. I reference them to see how often I make changes or access them. If they get used infrequently, then this is as far as they go. If I find that I am modifying the file a lot or refining a process that will span multiple stories or releases, then I know it deserves to be part of the main set of How-To’s. Also, if I find How-To’s that are out of date or no longer needed, I am encouraged to remove them or fold them into more up-to-date documents. Because every page has a revision control that dates back to when it was first made and tracks every change, we can always go back and review. By doing this, we are perpetually "gardening" the documentation and cultivating it for everyone else's benefit.
Conclusion
One of the most important things I have learned in my time at Socialtext is there are many ways to do things, and everyone has an impact on how to encourage others to do and be better. We have a culture that encourages communication and capturing as much of it as possible. Your organization may not be distributed, and sure, if it makes sense to directly talk with your team members, by all means do so. I would recommend, however, that you give our model a try for a few weeks. Pretend there's an ocean between you. You may become more productive than you could ever imagine.
