I'm a member of a seven-person development team, within an engineering organisation of five teams. Recently I have been thinking about how we communicate with each other within the team, and how we communicate with the other teams.
Project Website
The focal point for the team is our internal team website. The site is a web of content rooted at the main project page that serves as a portal into the whole project. The content is comprised of documents that describe our requirements, functional specifications, architecture, design documents, project plans, current status, build instructions, and testing results. This static content is stored in a revision control system, (we are using perforce), which provides us with backup, versioning, and an interface for developers to manipulate the site contents from their desk or home machines. There's also some dynamic content in the form of queries into the bug database, and reports from the continuous build and test machine.
We never email office documents as attachments, we always forward an http URL. This prevents anyone from having to read out of date documents, and ensures that everything worth writing into a document is under revision control, and is visible to anyone accessing the web pages, and that the documents actually live within a contextual web of information.
Team Mailing List
Within the team we use many means of communication: email, telephone, video conferencing, instant messaging, ad-hoc whiteboard discussions, and formal meetings for communicating. But, the most frequently used medium is the team mailing list. We use this list for collaborative problem solving at all stages of the project, and for tight co-ordination of our individual activities. From a basis of effective and efficient communication we have built a team that is self-organising and self-directed. We have a team lead rather than an engineering manager.
Most of the team members, although at a new company, have been working together for a number of years. For two of us this is our third company together, and for five of us this is our second. This familiarity with each other, and the trust that we have built with each other, makes open and honest communication much easier.
It might seem strange to be explaining the use of a mailing list, but our team has developed a way of working that may seem odd at first sight. There is a lot of traffic on the list, perhaps two hundred messages a day, and some of it is terse, and not always relevant to everyone on the list. But, this is all intentional, resulting from our need to work around a number of organisational problems.
Firstly, people tend to work the hours that suit them best. At Netscape the QA team tended to work late afternoon until midnight. We needed a way of communicating information between teams across time when not all participants were present. In the morning the engineers would pick up their test results messages, and would have a fresh build ready by the end of the day.
Secondly, as the team expanded we started having more people who worked from home some days, people who worked out of state, and who even worked in different time zones. Again the only way of communicating efficiently across time and space was email.
Both these factors contribute to the team becoming a virtual team, which may only physically congregate at the same time and place as infrequently as once every couple of months.
An empirical study I once read suggested that a significant proportion of an engineer's day is spent communicating information to other team members. Where a virtual team breaks down is if the majority of that communication is taking place as face-to-face chatting between cubes. In a packed cube farm office you overhear an awful lot of other people's conversations, sometimes you tune in, or join in, or tune out, and sometimes you tell them in no uncertain terms to go to the other end of the building. But, the point here is that it's important to recreate the same effect on the mailing list. The virtual team members must have the opportunity to overhear a conversation between other people, and for their own conversations to be overheard by others too.
Two researchers, Heath and Luff, named this behaviour "talking-out-loud" and "overhearing". In an ethnographic study they performed in 1991 they found that workers in the London Underground control rooms would often seemingly talk to themselves as they worked. This allowed their colleagues to have peripheral awareness of their actions, who would sometimes take supportive, collaborative action to aid them.
Talking-out-loud with email is easy, just cc the mailing list. Some of our messages are addressed to an individual, or group of individuals, or just to the list at large. There are specific topics of discussion, cries for help, and moaning about difficulties. People have no obligation to respond, but they become attuned to the activities of everyone around them, even though they are not physically present.
Taken to an extreme, you might see a conversation someone is having with him/herself. Nobody pitches in with a comment, and they resolve the problem themself and follow-up their own message for completeness and to let others know that the issue is closed.
The feeling of virtual presence is enhanced by the use of Instant Messaging clients, like Yahoo Messenger. Beyond enabling speedy peer-to-peer interactive communication, you also get a list of your team members currently logged into the network. You get a warm fuzzy team membership feeling that there is help and advice there if you need it.
All this results in a very chatty mailing list. Single sentence messages being exchanged between two parties and echoed to the list. Instant Messenger services do not have the useful property of automatically archiving the conversations, or allowing others to listen in to what's going on. So, we chat by email instead.
The volume of email messages can be hard to deal with. But, it also encourages people to close issues, and not to revive them. An issue can never be left dangling; otherwise the email just keeps on backing up. The issue must be closed out with a decision, a bug, a work item, a document, whatever ever it takes to end the thread. Then the thread can be deleted or archived. Archiving decisions is important as it prevents wasted time when an issue resurfaces from another direction. Archived messages can also form the basis of design documents, bug reports, and FAQ web pages. The only messages in my inbox are those that I have read and need to take some action on, or that I am expecting someone else to take an action upon. So, at any one time I have about fifty messages to deal with, and I pay more attention to some topics than others, as we each have our specialized areas within the team.
Another aid in dealing with the constant message flow is that all messages must be written clearly and effectively. The author must take into account the knowledge of the listener, and make the effort to write briefly and unambiguously, so that the reader can discern exactly the point being made without a game of twenty questions. The number of issues in a message should be low, and the subject line of the message should be kept pertinent to the content, even if this means changing the subject of the message when replying.
And, finally, as in all things, good team communication requires intellectual honesty, openness, and a good sense of humour. There are always extra points for jokes!
PS: Many of the thoughts here are echoed by an article that appeared in the January 2000 issue of Communications of the ACM by Mike Robinson, Mikko Kovalainen and Esa Auramäki. It's title, 'Diary as Dialogue in Papermill Process Control', may not seem particularly relevant. But, it describes how a team of paper mill workers make use of an electronic diary as a means of inter and intra team communications.
Mark Radford
In Overload 41 I failed to introduce a new member of the Overload editorial team: Mark Radford studied Maths and Physics at Trent Polytechnic, Nottingham, graduating in 1986. Having found the computing part of the course more interesting embarked on a career in software development, working over the last twelve years for various organisations, using a variety of languages and platforms. He has been a member of the BSI C++ panel since November 1998, and was a member of the UK delegation to ISO WG21 in April 1999. Mark has volunteered to help source and review articles for publication.
